Herzlich willkommen im SEO Forum der ABAKUS Internet Marketing GmbH
registrieren registriertes Mitglied
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: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 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: 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 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: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:
Code: Alles auswählen
1.2.3.4 - - [14/Dec/2016:12:00:35 +0000] "GET /mein-artikel HTTP/1.1" 200 13291 "https://l.facebook.com/l.php?u=https%3A%2F%2Fbeispiel.de%2Fmein-artikel&h=nAQFnCmF1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.91 Safari/537.36"
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.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? [...]
Dann steht wahrscheinlich in den RFCs von w3c zu https auch voelliger unsinn.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.
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.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 [..]
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.[...] 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.
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.Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
Nein - das ist schon seit ein paar jahren bei allen grossen browsern standard, dass bei https keine kompletten referer weitergegben werden!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.
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 ärgernnerd 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.
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.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.
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:Ich weiss durchaus wie referer funktionieren, und bin auch schon deutlich laenger beruflich im netz unterwegs als du mit deinen 7 jahren.
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.nerd hat geschrieben:[...] deine aussage "[...]" ist und bleibt falsch, da Facebook wie mehrfach verlinkt diese gesuchten informationen eben nicht zur verfuegung stellt.
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.Infinitnet hat geschrieben: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.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? [...]
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: [...] ich habe NICHT nach der clickenden person gefragt, mich interessiert NUR der ort des links [...]
gruß
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.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.