Wie baut Google seine SERPs auch, was wird getrackt und wie landet man gezielt in einem A/B-Test der Google? Diesen und andere Dinge werden in diesem Vortrag auf den Grund gegangen. Ein bunter Strauß an Learnings bei der Analyse der Google SERPs.

1. Von Protocol Buffer und anderen Dingen
Reverse Engineering Google SERPs

2. Wer ich bin
2 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Valentin Pletzer
Head of SEO @ BurdaForward
https://twitter.com/VorticonCmdr
https://www.xing.com/profile/Valentin_Pletzer
https://plus.google.com/+ValentinPletzer
valentin.pletzer@burda-forward.de
http://www.chip.de/
http://www.focus.de/
https://www.bestcheck.de
http://www.netmoms.de/
https://www.finanzen100.de/
http://www.huffingtonpost.de/
https://weather.com/de-DE

3. Browser-spezifisches HTML
3 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Beispiel Chrome <-> Firefox

4. User-spezifisches HTML
4 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Beispiel aus der Praxis: A/B-Test für „speedtest“
App Engine https://cloud.google.com/appengine/docs/standard/#trafficsplitting

5. Google A/B-Test reproduzieren
5 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
EditThis Cookie
• Eigentlich recht einfach: NID
• Das NID-Cookie enthält eine eindeutige ID,
über die Google Ihre bevorzugten
Einstellungen und andere Informationen
speichert, insbesondere Ihre bevorzugte
Sprache (z. B. Deutsch), wie viele
Suchergebnisse pro Seite angezeigt werden
sollen (z. B. 10 oder 20) und ob der Google
SafeSearch-Filter aktiviert sein soll.
• EditThisCookie-Extension “Für Incognito
Modus zulassen“
• Cookie laden und speichern
• Idee: Plugin mit Datenbank für NID-Cookies
Quelle: https://www.google.com/policies/technologies/types/

6. Location Header & Cookie
6 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
wo bin ich?
• UULE-Cookie
• x-geo-Header
• Base64-codierte Location-Daten
role: CURRENT_LOCATION
producer: DEVICE_LOCATION
radius: 65000
latlng <
latitude_e7: 374248743
longitude_e7: -1220943074
>
• 374248743 / 1e7 = 37.4248743 (lat)
• -1220943074 / 1e7 = -122.0943074 (lng)
x-geo: a
cm9sZTogQ1VSUkVOVF9MT0NBVElPTgpwcm9kdWNlcjogREVWSUNFX0xPQ
0FUSU9OCnJhZGl1czogNjUwMDAKbGF0bG5nIDwKICBsYXRpdHVkZV9lNzog
Mzc0MjQ4NzQzCiAgbG9uZ2l0dWRlX2U3OiAtMTIyMDk0MzA3NAo+

7. Chrome Erweiterung
7 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
gs location changer
https://chrome.google.com/webstore/detail/gs-location-changer/blpgcfdpnimjdojecbpagkllfnkajglp

8. Data-Attribute ved
8 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Tracking-Daten im HTML

9. ved deep dive
9 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Kleine Geheimnisse im Quellcode (base64)
<div data-ved="0ahUKEwiMsveD6sHZAhWEL1AKHZ47BtwQGggr"> ???
• data-* attributes allow us to store extra information on standard, semantic HTML elements without
other hacks such as non-standard attributes, extra properties on DOM, or Node.setUserData().
• Mal wieder Base64-Encoding, aber: Das erste Zeichen muss weg (die 0)
• Base64
• Zur Kodierung werden jeweils drei Byte des Bytestroms (= 24 Bit) in vier 6-Bit-Blöcke aufgeteilt.
• Falls die Gesamtanzahl der Eingabebytes nicht durch drei teilbar ist, wird der zu kodierende Text am Ende mit
aus Nullbits bestehenden Füllbytes aufgefüllt, sodass sich eine durch drei teilbare Anzahl an Bytes ergibt.
atob('ahUKEwiMsveD6sHZAhWEL1AKHZ47BtwQGggr‘)
==

10. ved deep dive
10 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Kleine Geheimnisse im Quellcode (protocol buffer)
• ab Mitte 2012 als nützlicher Teil des Google Referrers erkannt
• damals aber nicht wirklich „verstanden“
• August 2013 dann von Benjamin Schulz korrekt als Protocol
Buffer identifiziert
Links:
• https://moz.com/blog/decoding-googles-referral-string-or-how-i-survived-secure-search
• http://gqs-decoder.appspot.com/
• https://github.com/google/protobuf/releases

11. ved deep dive
11 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Procol Buffer richtig dekodieren – so geht‘s

12. ved deep dive
12 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Durchnummeriert – 10 blue links and more
0
1
3
0 1 2
4
13
14 15 16
17 18 19
23 23 23 23 23
24
25
25

13. ved Zusammenfassung
13 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Nicht perfekt aber schon recht hilfreich
• Nützlich vor allem um Ergebnis-Typen zu identifizieren
• Problematisch um Ergebnis-Position auszulesen (Featured-Snippet-Problematik)
• hveid als unbekannte Variable

14. Google Server
14 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
Gib mir „alle“ IP-Adressen
$ host www.google.de
www.google.de has address 172.217.19.67
www.google.de has IPv6 address 2a00:1450:4005:80b::2003
$ whois -h whois.radb.net 172.217.19.67
route: 172.217.19.0/24
descr: Google
origin: AS15169
notify: radb-contact@google.com
mnt-by: MAINT-AS15169
changed: radb-contact@google.com 20150728
source: RADB
$ whois -h whois.radb.net '!gAS15169'
A111637
66.249.64.0/20 66.249.80.0/20 74.125.57.240/29 216.239.44.0/24 216.239.45.0/24 23.251.128.0/23
23.251.128.0/24 23.251.129.0/24 23.251.130.0/23 23.251.130.0/24 23.251.131.0/24 23.251.132.0/23
23.251.132.0/24.....
=> grob 14.500 IPs mit Google Search (58 x 250)

15. Sind alle Google SERPs gleich
15 Reverse Engineering Google SERPs | Valentin Pletzer | BurdaForward GmbH
58 IPs = 39 + 8 + 5 + 2 + 2 + 1 + 1 unterschiedliche SERPs
Setup:
• 58 IPs
• selbe Location (Berlin)
• etwa gleicher Zeitpunkt (innerhalb von 3 Minuten)

16. Fragen?
Danke