ABAKUS

Verfasst: **12.12.2016, 10:48**

Hallo Forum,
unsere Seite kann seit gestern einen starken Zuwachs an Besuchern verzeichnen. Mich würde jetzt interessieren, gibt es eine Möglichkeit die genaue Quelle zu erfahren woher die Besucher kommen? Ich habe Google Analytics zwar eingebunden bin aber nicht wirklich fit was die Benutzung betrifft. Geschaut habe ich bei "Akquisition" -> "Alle Zugriffe" -> und an dieser Stelle sehe ich dass die Nutzer von Facebook kommen. Nur wie ist es möglich herauszubekommen von welchem Posting oder welchen Link sie auf meine Website kommen? Geht das überhaupt?

Viele Grüße und einen schönen dritten Advent
Tom

Verfasst: **15.12.2016, 10:11**

Das kannst du am Referrer Teil der Access Logs sehen. Um auf diese Logs ansehnlicher zugreifen zu können, kannst du AWStats oder Webalizer verwenden, was dir dein Hosting-Anbieter zur Verfügung stellen sollte.

Verfasst: **15.12.2016, 13:16**

Infinitnet hat geschrieben:Das kannst du am Referrer Teil der Access Logs sehen. Um auf diese Logs ansehnlicher zugreifen zu können, kannst du AWStats oder Webalizer verwenden, was dir dein Hosting-Anbieter zur Verfügung stellen sollte.

Das ist unsinn, da bei HTTPS (Facebook!) der browser keinen referer an externe domains schickt, und diese angaben in den logs dann natuerlich fehlen. Facebook selbst stellt sicher das diese angaben auch den eigenen server nie verlassen, indem es keine direkten links setzt, sondern externe links grundsaetzlich weitergeleitet werden, wobei der referer auch wieder aus den headern entfernt wird:

https://www.facebook.com/notes/facebook ... 382738919/

"Facebook is one site where referrers don’t really belong. As part of our continued efforts to protect users’ privacy, we proactively protect our users from exposing how they navigated to an external site."

Soll heissen du weisst nicht, von welchen usern, postings oder gruppen deineseite geteilt wurde wenn sie auf facebook erscheint, und kannst es auch auf deinem server nicht rausfinden.

Verfasst: **15.12.2016, 13:34**

nerd hat geschrieben: Das ist unsinn, da bei HTTPS (Facebook!) der browser keinen referer an externe domains schickt, und diese angaben in den logs dann natuerlich fehlen.

Das ist völliger Unsinn. Der HTTP-Header unterscheidet sich bei HTTP und HTTPS nicht und selbstverständlich ist der Referrer auch Bestandteil des HTTP-Headers, wenn die Verbindung über HTTPS bzw. TLS hergestellt wird.

nerd hat geschrieben:Facebook selbst stellt sicher das diese angaben auch den eugenen server nie verlassen, indem es keine direkten links setzt, sondern externe links grundsaetzlich weitergeleitet werden, wobei der referer auch wieder aus den headern entfernt wird:

Das stimmt zum Teil. Tatsächlich verwendet Facebook Weiterleitungen, um die genaue Quelle des Klicks zu verschleiern, sodass sie nicht auf einen bestimmten Nutzer oder eine Gruppe zurückzuführen ist. Trotzdem ist der Referrer noch Bestandteil des HTTP-Headers. Sieht dann ziemlich genau so aus:

Code: Alles auswählen

1.2.3.4 - - &#91;14/Dec/2016&#58;12&#58;00&#58;35 +0000&#93; "GET /mein-artikel HTTP/1.1" 200 13291 "https&#58;//l.facebook.com/l.php?u=https%3A%2F%2Fbeispiel.de%2Fmein-artikel&h=nAQFnCmF1" "Mozilla/5.0 &#40;Windows NT 6.1; WOW64&#41; AppleWebKit/537.36 &#40;KHTML, like Gecko&#41; Chrome/54.0.2840.91 Safari/537.36"

Der Titel dieses Threads ist "Genaue Besucherquelle wie ermitteln?" und die darin enthaltene Frage lautet "Mich würde jetzt interessieren, gibt es eine Möglichkeit die genaue Quelle zu erfahren woher die Besucher kommen?". Meine Antwort bezieht sich genau auf diese Frage und nicht ausschließlich auf die Besuche von Facebook-Nutzern. Vielleicht habe ich die Frage nicht richtig verstanden, aber ich denke, dass der OP allgemein wissen möchte, über welche genauen Quellen (URLs) die Besucher auf seine Website kommen und beschränkt sich dabei nicht auf Facebook.

Verfasst: **15.12.2016, 16:49**

inifinitnet,
du beschreibst hier nur die quelle "facebook" u. ich sehe in deiner loesung keinen ansatz dafuer, dass man hier DEN ORT innerhalb v. FACEBOOK nachvollziehen kann. insofern ist deine loesung zwar voellig korrekt, beschreibt aber keinesfalls die GENAUE BESUCHERQUELLE aus dem FACEBOOK-UNIVERSUM.
hast du denn eine loesung hierfuer vorliegen? falls ja: mich wuerde diese sogar enorm brennend interessieren. ^^
lg

Verfasst: **15.12.2016, 18:51**

hanneswobus hat geschrieben:[...] insofern ist deine loesung zwar voellig korrekt, beschreibt aber keinesfalls die GENAUE BESUCHERQUELLE aus dem FACEBOOK-UNIVERSUM.
hast du denn eine loesung hierfuer vorliegen? [...]

Soweit ich weiß existiert dafür leider keine Lösung und ich wüsste auch nicht, wie diese technisch umsetzbar wäre, solange Facebook den Referrer anonymisiert. Zudem ist das in Deutschland datenschutzrechtlich sehr problematisch. Es darf bei dem Besuch einer Website ohne eine ausdrückliche Einwilligung (eine Klausel in der Datenschutzerklärung reicht nicht) keine genaue Identifizierung der Personen stattfinden. Du darfst ja auch nicht Google Analytics einsetzen, wenn "anonymizeIp" im JavaScript nicht auf "true" gesetzt wird (andere Dinge sind hier auch noch zu beachten). Da ein Facebook-Profil normalerweise an eine reale Person gebunden ist (mit Klarnamen, wie es die Nutzungsbedingungen sogar fordern), wäre es von Facebook also sehr fahrlässig und in Deutschland dann datenschutzrechtlich wohl auch ein großes Problem, wenn personenbezogene Daten wie die Facebook-ID beim Klicken von exernen Links an die unbekannten Betreiber der Ziel-Website im HTTP-Header weitergegeben werden. Für Online-Marketer wäre das natürlich ein Traum (wie auch z.B. der Facebook Pixel und sonstige Retargeting-Tools), datenschutzrechtlich ist das aber eher ein Albtraum.

Verfasst: **15.12.2016, 22:31**

Infinitnet hat geschrieben: Das ist völliger Unsinn. Der HTTP-Header unterscheidet sich bei HTTP und HTTPS nicht und selbstverständlich ist der Referrer auch Bestandteil des HTTP-Headers, wenn die Verbindung über HTTPS bzw. TLS hergestellt wird.

Dann steht wahrscheinlich in den RFCs von w3c zu https auch voelliger unsinn.
HTTP und HTTPS unterscheiden sich hier! Das S steht fuer Secure. Deswegen werden bei HTTPS auch keine referer an ausgehende(!) oder drittdomains weitergegeben, da prinzipiell davon ausgegangen wird das die URLs sensitive informatioen haben koennen die nicht nach aussen gegeben werden sollen, und damit fuer dritte sichtbar werden.

Verfasst: **16.12.2016, 08:59**

nerd hat geschrieben: Dann steht wahrscheinlich in den RFCs von w3c zu https auch voelliger unsinn.
HTTP und HTTPS unterscheiden sich hier! Das S steht fuer Secure. Deswegen werden bei HTTPS auch keine referer an ausgehende(!) oder drittdomains weitergegeben [..]

Erstens sind RFCs lediglich Richtlinien und stellen keinesfalls die Norm dar. Des Weiteren steht in den RFCs kein Unsinn, aber du verstehst den entsprechenden Teil des Textes offensichtlich nicht. Das S steht für Secure, richtig, aber das bezieht sich auf die Netzwerkebene und nicht auf die Anwendungsebende, bzw. das HTTP-Protokoll. Obwohl die Kommunikation über HTTPS sozusagen innerhalb eines TLS-Tunnels stattfindet, wird innerhalb dieses Tunnels immer noch HTTP gesprochen. Das S bedeutet also nicht, dass weniger Daten übermittelt oder die HTTP-Header reduziert werden, sondern lediglich, dass die Daten auf Netzwerkebene nicht im Klartext übertragen werden. Auf Anwendungsebene, also wenn die Daten auf dem Ziel-Server ankommen, werden diese entschlüsselt und ganz normal verarbeitet und geloggt. Deshalb unterscheiden sich die Access Logs dann letztendlich auch nicht.

[...] it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information.

Schöne Theorie, die aber auf der Client-Seite umgesetzt werden muss und kann, siehe hier. Wurde zum Teil auch von bspw. von Chrome adaptiert.

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

Hier ist ebenfalls von den Clients (in diesem Fall also Browsern) die Rede und nicht von irgendwelchen serverseitigen Maßnahmen oder gar irgendwelchen Standards, die durch die Verwendung von HTTPS "automatisch aktiviert" werden.

Es kann natürlich jeder die Weitergabe von Referrern unterbinden, indem die entsprechende Einstellung im Browser geändert wird. Umsetzten tut das allerdings fast niemand und mit HTTPS hat das Ganze eben nichts zu tun.

Ich komme ursprünglich aus der Webhosting-Branche, in der ich 7 Jahre lang gearbeitet habe. Insbesondere habe ich dort mit Informationssicherheit und der Mitigation von (ua. Layer 7, also auf Anwendungsebende stattfindenden auf HTTP(S) basierenden) DDoS-Angriffen zu tun gehabt und behaupte mal, dass ich in dieser Zeit genug Traffic-Muster und -Pakete studiert habe, um hier eine halbwegs qualifizierte Aussage treffen zu können.

Verfasst: **16.12.2016, 09:43**

Infinitnet hat geschrieben: Es kann natürlich jeder die Weitergabe von Referrern unterbinden, indem die entsprechende Einstellung im Browser geändert wird. Umsetzten tut das allerdings fast niemand und mit HTTPS hat das Ganze eben nichts zu tun.

Nein - das ist schon seit ein paar jahren bei allen grossen browsern standard, dass bei https keine kompletten referer weitergegben werden!
Ich habe es soeben nochmal selbst ueberprueft, und wenn du bei google einen suchbegriff eingibt dann sieht die zielseite nur noch "https://www.google.com/" im referer, aber alle url parameter wie ?q=test werden verworfen - das kannst du auch selbst bei dir nachpruefen.

Hier in diesem forum war auch das geheule los, als google damals die ganze suche auf HTTPS umgestellt hat, und praktisch ueber nacht alle referer (und damit die gewissheit, fuer welche keywords die eigene seite rankt!) aus den servereigenen logs und GA verschwunden sind, bzw. auf "not provided" gesetzt wurden.
Selbes thema wie das des OP hier: Seite laeuft auf HTTPS, externe domains bekommen keinen referer mehr uebergeben.

Verfasst: **16.12.2016, 10:00**

nerd hat geschrieben: Nein - das ist schon seit ein paar jahren bei allen grossen browsern standard, dass bei https keine kompletten referer weitergegben werden!
Ich habe es soeben nochmal selbst ueberprueft, und wenn du bei google einen suchbegriff eingibt dann sieht die zielseite nur noch "https://www.google.com/" im referer, aber alle url parameter wie ?q=test werden verworfen - das kannst du auch selbst bei dir nachpruefen.

Das ist dann ein anonymisierter Referrer, aber trotzdem ein Referrer. Google anonymisiert die Referrer, genau wie Facebook. Das hat aber immer noch nichts mit HTTPS zu tun, auch wenn "Not Provided" zusammen mit HTTPS eingeführt wurde, um zusätzlich die Privatsphäre der Nutzer zu schützen (und SEOs zu ärgern

).

nerd hat geschrieben: Hier in diesem forum war auch das geheule los, als google damals die ganze suche auf HTTPS umgestellt hat, und praktisch ueber nacht alle referer (und damit die gewissheit, fuer welche keywords die eigene seite rankt!) aus den servereigenen logs und GA verschwunden sind, bzw. auf "not provided" gesetzt wurden.

Wie nun bereits mehrfach erwähnt, hat das Ganze nichts mit HTTPS zu tun. Das Anonymisieren von Referrern ist eine seperate Angelegenheit, die serverseitig mit und ohne HTTPS umgesetzt werden kann, um die Nutzer zu schützen, die Referrer nicht selbst in ihrem Browser deaktivieren. Wird aber nur von einem Bruchteil der Website-Betreiber so umgesetzt.

Da ich keine Lust mehr habe, mich ständig zu wiedeholen, verweise ich einfach mal auf Wikipedia: https://de.wikipedia.org/wiki/Referrer

Lies dir hier bitte den zweiten Paragraphen (genau!) durch.

Falls du es danach immer noch nicht verstanden hast, lies dir bitte folgenden Artikel durch, welcher auch deine Aussage bezüglich Google und "Not Provided" widerlegt und den oben erwähnten Paragraphen des Wikipedia-Artikel in einfacher Sprache zusammenfasst: https://www.trustagents.de/blog/die-sac ... und-google

Verfasst: **16.12.2016, 11:53**

Ich weiss durchaus wie referer funktionieren, und bin auch schon deutlich laenger beruflich im netz unterwegs als du mit deinen 7 jahren.

Wie deine ausfuehrungen dem OP helfen verstehe ich trotzdem nicht, denn deine aussage "Das kannst du am Referrer Teil der Access Logs sehen. Um auf diese Logs ansehnlicher zugreifen zu können, kannst du AWStats oder Webalizer verwenden, was dir dein Hosting-Anbieter zur Verfügung stellen sollte." ist und bleibt falsch, da Facebook wie mehrfach verlinkt diese gesuchten informationen eben nicht zur verfuegung stellt.

Verfasst: **16.12.2016, 12:05**

nerd hat geschrieben:Ich weiss durchaus wie referer funktionieren, und bin auch schon deutlich laenger beruflich im netz unterwegs als du mit deinen 7 jahren.

Alle deine Aussagen in diesem Thread deuten auf das Gegenteil hin. Wer "länger im Netz unterwegs ist", spielt dabei ganz offensichtlich keine Rolle. Zumal wir wahrscheinlich in vollständig unterschiedlichen Bereichen unterwegs waren, die unterschiedliches Fachwissen erfordern.

nerd hat geschrieben:[...] deine aussage "[...]" ist und bleibt falsch, da Facebook wie mehrfach verlinkt diese gesuchten informationen eben nicht zur verfuegung stellt.

Muss ich mich denn wirklich ständig wiederholen? Die Frage des OP hat sich meiner Auffassung nach nicht auf Facebook bezogen, sondern allgemein auf genauere Informationen bezüglich der Besucherquellen. Google Analytics zeigt nur die Domains der Referrer an, nicht aber die gesamte URL. Insofern sind AWStats, Webalizer oder eben auch direkt die rohen Access Logs sehr wohl eine Möglichkeit, um an genauere Informationen der Besucherquelle zu gelangen, da diese den gesamten Referrer inklusive URL beinhalten, solange der nicht durch eine Weiterleitung entfernt wurde, wie es in wenigen Ausnahmefällen wie Facebook und Google der Fall ist.

Verfasst: **16.12.2016, 23:39**

Infinitnet,
dein hinweis auf die stats-tools stimmt nicht u. ich sehe bspw. auf meinem server ganz sicher keine moeglichkeit, den clickort innerhalb des fb-universums genauestens zu identifizieren u. mir ist im moment nicht klar, um was es dir hier geht.
ich sehe es auch so, dass du die frage nach den genauen besucherquellen nur "ein wenig" beantwortest u. keinesfalls ins technische detail gehst. ich mag zwar nicht unbedingt diese ich-bin-schon-laenger-aktiv-als-du-schiene, aber du solltest auch bedenken, wie klischeehafte verweise auf wikipediaartikel wirken koennen.

aber egal:
ich erlaube mir mal ein paar gedankengaenge:
das not-provided problem laesst sich ueber die einstiegsseiten auf bspw. via api zu webmastertools, xovi o. sistrix IM ANSATZ aufloesen
das problem mit den fb-clicks koennte man eventuell ueber die pruefung auf offene (!) fb-pages loesen. hier laesst sich via api auslesen, ob ein link zu projekt - lalala steht u. es lassen sich hier PROGNOSEN oder AHNUNGEN zu eventuellen traffic anstellen, indem mal halt dauerhaft likes, comments u. shares erfasst u. interpretiert.

Verfasst: **16.12.2016, 23:43**

Infinitnet hat geschrieben:
hanneswobus hat geschrieben:[...] insofern ist deine loesung zwar voellig korrekt, beschreibt aber keinesfalls die GENAUE BESUCHERQUELLE aus dem FACEBOOK-UNIVERSUM.
hast du denn eine loesung hierfuer vorliegen? [...]
Soweit ich weiß existiert dafür leider keine Lösung und ich wüsste auch nicht, wie diese technisch umsetzbar wäre, solange Facebook den Referrer anonymisiert. Zudem ist das in Deutschland datenschutzrechtlich sehr problematisch. Es darf bei dem Besuch einer Website ohne eine ausdrückliche Einwilligung (eine Klausel in der Datenschutzerklärung reicht nicht) keine genaue Identifizierung der Personen stattfinden. Du darfst ja auch nicht Google Analytics einsetzen, wenn "anonymizeIp" im JavaScript nicht auf "true" gesetzt wird (andere Dinge sind hier auch noch zu beachten). Da ein Facebook-Profil normalerweise an eine reale Person gebunden ist (mit Klarnamen, wie es die Nutzungsbedingungen sogar fordern), wäre es von Facebook also sehr fahrlässig und in Deutschland dann datenschutzrechtlich wohl auch ein großes Problem, wenn personenbezogene Daten wie die Facebook-ID beim Klicken von exernen Links an die unbekannten Betreiber der Ziel-Website im HTTP-Header weitergegeben werden. Für Online-Marketer wäre das natürlich ein Traum (wie auch z.B. der Facebook Pixel und sonstige Retargeting-Tools), datenschutzrechtlich ist das aber eher ein Albtraum.

ich fragte hier nicht nach dem datenschutz. mich hat nur interessiert, ob dir eine technische moeglichkeit bekannt ist. ob du diese umsetzt oder nicht umsetzt oder hier freiwillig beschreibst, ist eine voellig andere geschichte. auch habe ich nicht nach google-analytics gefragt u. wie man das spielzeug einsetzt, ist jedem bekannt.
was fb betrifft:
ich habe NICHT nach der clickenden person gefragt, mich interessiert NUR der ort des links PLUS die clickvolumina u. mir fallen durchaus beispiele aus dem socialumfeld ein, wo die trafficvolumina voellig problemlos u. anonymisiert u. sehr sauber ausgegeben werden. wenn "online-marketer" solche dinge nicht kennen u. da in "traumphasen" herumwandern, sollten diese "marketeers" den job wechseln.
also: wenn du da in die technik hinein schauen willst oder sogar kannst, empfehle ich dir die recherche nach bspw. (!) der bit.ly-api.
gruß

Verfasst: **17.12.2016, 09:17**

hanneswobus hat geschrieben: [...] ich habe NICHT nach der clickenden person gefragt, mich interessiert NUR der ort des links [...]
gruß

Dann ist die kurze Antwort eben: Nein, ist (meines Wissens) technisch nicht möglich solange Facebook da nicht mitspielt. Meine Antwort mit AWStats und Webalizer bezog sich allgemein auf genauere Besucherquellen, als GA anzeigt. Die paar Websites, die den Referrer durch eine Weiterleitung anonymisieren (Facebook, Google, dieses Forum hier) sind davon ausgeschlossen.

hanneswobus hat geschrieben:also: wenn du da in die technik hinein schauen willst oder sogar kannst, empfehle ich dir die recherche nach bspw. (!) der bit.ly-api.

Magst du das genauer erläutern? Bit.ly ist ein URL-Shortener mit integrierten Analytics. Dort kommen keine anderen HTTP-Header an, als auch an deinem Webserver wenn kein URL-Shortener verwendet wird. Ein API wird dafür genutzt, um programmatisch auf die (meist) gleichen Funktionen zuzugreifen, auf die sonst über das User Interface zugegriffen wird. Ich verstehe noch nicht, warum ich mir das API von Bit.ly ansehen soll und was das mit dem Thema hier zu tun hat, erschließt sich mir leider noch nicht.