Yahoo Proxy: Regionsversion, Ratensteuerung und mobile Ergebnisse

Die Yahoo-Suche ist eine Struktur mit eigener Oberflaeche und eigener Ergebnisanordnung, die im Hintergrund jedoch von einer gemeinsamen Suchinfrastruktur gespeist wird. Diese Zweiteilung hat fuer die messende Seite eine unmittelbar praktische Folge: Die Praesentationsschicht ist Yahoos Entscheidung, der grosse Teil des Rankings dagegen die einer anderen Quelle. Vergleiche, die beides nicht trennen, sind irrefuehrend.

Ein zweites Detail ist, dass einige Laenderdienste unter der Marke von eigenstaendigen Unternehmen betrieben werden. Eine Laenderversion kann sich von einer anderen nicht nur sprachlich, sondern auch strukturell unterscheiden. Vor Beginn der Messung muss klar sein, welche Version Sie messen.

Die folgenden Abschnitte behandeln zuerst die Schichten der Seite, dann die Regions- und Spracheinstellungen, anschliessend die Temposteuerung und den Geraeteunterschied. Die Abschnitte zu Einrichtung und Grenzen stehen am Ende; mit der Einrichtung zu beginnen, ohne geklaert zu haben, welche Frage Sie beantworten wollen, ist Zeitverschwendung.

Die Schichten der Ergebnisseite trennen

Auf einer Yahoo-Ergebnisseite liegen mindestens drei Schichten ineinander: die organische Linkliste, standortsensible lokale und News-Bloecke sowie Werbeflaechen. Diese Schichten befinden sich auf demselben Bildschirm, reagieren aber nicht im gleichen Mass auf dieselben Eingaben. Die organische Liste richtet sich nach Abfrage und Land, der lokale Block nach dem Standort und die Werbeflaeche nach einer eigenen Zuordnungslogik.

Beginnen Sie zu messen, ohne diese Unterscheidung zu treffen, erfassen Sie jede beobachtete Veraenderung als "Ranking hat sich geaendert". Tatsaechlich ist jedoch haeufig die organische Liste unveraendert geblieben, waehrend sich der Block darueber geaendert hat und die wahrgenommene Position dadurch nach unten gerutscht ist. Jede Schicht in einer eigenen Spalte Ihrer Messtabelle zu fuehren, verhindert diese Verwirrung von vornherein.

Ein Proxy wirkt sich nicht auf alle diese Schichten gleich aus. Das Land der Exit-Adresse erzeugt bei lokalen und News-Bloecken die sichtbarste Wirkung; in der organischen Liste ist die Wirkung zurueckhaltender; bei Werbeflaechen sind andere Variablen im Spiel, und eine Messung per Proxy liefert hier den schwaechsten Nachweis. Bei Arbeiten, in denen die Anzeigensichtbarkeit das eigentliche Thema ist, kommen Variablen wie Budget, Targeting und Auslieferungsreihenfolge ins Spiel, die Sie nicht einsehen koennen - einen einzelnen Screenshot als Beleg zu werten, waere daher irrefuehrend.

Die Schichtentrennung hat noch einen Nutzen: die Fehlerdiagnose. Ist nur der lokale Block verschwunden, sehen Sie sich den Standortkontext an, hat sich nur die Sprache geaendert, die Client-Header, und hat sich alles auf einmal geaendert, den Exit selbst.

Wie tragen Laenderversion und Spracheinstellung das Ergebnis?

Die Region wird an zwei verschiedenen Stellen bestimmt. Erstens dadurch, welche Laenderversion Sie aufrufen; zweitens dadurch, aus welchem Land die Anfrage kommt. Stimmen diese beiden nicht ueberein, entsteht eine gemischte Seite: Die Oberflaeche wird nach einem Land, die standortsensiblen Bloecke werden nach einem anderen Land zusammengestellt. Deshalb muessen bei der Messung beide gemeinsam fixiert werden.

Die Sprache ist eine eigene Achse und wird in der Regel aus dem vom Browser gemeldeten Accept-Language -Header und der Praeferenz in der Oberflaeche gelesen. Der Proxy sendet diesen Header nicht und veraendert ihn nicht. Wenn Sie einen Exit in Frankreich nutzen und einen tuerkischen Sprach-Header senden, geben Sie der Engine zwei widerspruechliche Hinweise; zu erklaeren, warum das Ergebnis so ausfaellt, wird dadurch ebenfalls schwieriger. Bei europaeischen Messungen werden haeufig Exits in Frankreich, Italien und Grossbritannien genutzt; in diesen Laendern ist die Anbietervielfalt gross, und da Oberflaechensprache und Marktsprache meist uebereinstimmen, sinkt das Risiko widerspruechlicher Signale.

Es gibt noch eine dritte Variable: die Abfrage selbst. Werden zwei Abfragen mit derselben Bedeutung in unterschiedlichen Sprachen formuliert, kommt eine voellig andere Ergebnismenge zurueck. Fuehren Sie einen regionalen Vergleich durch, formulieren Sie die Abfrage in der Sprache des Zielmarkts; eine Abfrage in Ihrer eigenen Sprache ueber einen Exit in einem anderen Land zu senden, bildet das tatsaechliche Suchverhalten dieses Markts nicht ab.

Fuer die Laenderversionen im asiatischen Raum ist zusaetzliche Aufmerksamkeit noetig: In einigen Laendern wird der Dienst unter der Marke von einem eigenstaendigen Unternehmen betrieben, und die Struktur unterscheidet sich deutlich. Beim Messen dieser Versionen sind regionale Exits etwa in Japan oder Singapur erforderlich; vergleichen Sie die Ergebnisse jedoch nicht in derselben Tabelle mit anderen Laenderversionen, da im Hintergrund nicht einmal die Ranking-Quelle dieselbe sein muss.

Anfragetempo und die richtige Deutung der Verifizierungsseite

Um automatisiert wirkenden Traffic zu erkennen, betrachtet die Suchseite das Anfragemuster: die Regelmaessigkeit der Abstaende, die Zahl paralleler Streams, die Abfragedichte von derselben Adresse und die Konsistenz der mitgesendeten Client-Informationen. Ueberschreitet das Tempo eine bestimmte Schwelle, kommt statt der Ergebnisseite eine Verifizierungsseite oder eine Rate-Limit-Antwort zurueck.

Lesen Sie diese Seite nicht als Stoerung, sondern als Messinstrument. Sie sagt Ihnen, mit welcher Intensitaet die Arbeit nicht durchgefuehrt werden kann. Die richtige Reaktion ist, langsamer zu werden: Verdoppeln Sie die Wartezeit, nehmen Sie diesen Exit voruebergehend aus der Warteschlange, verteilen Sie die Abfragen ueber den Tag. Im gleichen Tempo weiterzumachen wiederholt die Antwort und fuehrt dazu, dass diese Adresse noch eine Weile gleich behandelt wird.

Antworten getrennt zu zaehlen ist die halbe Diagnose. Erfolgreiche Seite, Rate-Limit-Antwort, Verifizierungsseite und Timeout auf Netzwerkebene sind vier verschiedene Ereignisse, und alle vier verlangen eine andere Loesung. Ein Log, das alles als "Fehler" in einen Topf wirft, sagt Ihnen nicht, ob Sie das Problem beim Warteschlangentempo oder bei der Exit-Gesundheit suchen muessen.

Warteschlange, Backoff und Poolplanung

Eine gesunde Messwarteschlange besteht aus vier Entscheidungen, und alle werden von Anfang an festgelegt. Fixieren Sie die Region, starten Sie mit niedrigem Tempo, zaehlen Sie die Antworten klassifiziert und automatisieren Sie das Backoff. Ein Aufbau ohne diese vier Punkte stoppt sich am ersten intensiven Tag selbst.

Die Backoff-Logik ist einfach: Verdoppeln Sie bei einer Warnung die Wartezeit, halten Sie bei einer bestimmten Obergrenze an und senken Sie die Zeit bei erfolgreicher Antwort schrittweise wieder ab. Setzen Sie nicht abrupt zurueck; eine einzelne erfolgreiche Antwort bedeutet nicht, dass die Schwelle vollstaendig aufgehoben ist. Die Warteschlange zu verlangsamen statt vollstaendig zu stoppen verkuerzt die Gesamtdauer bis zur Fertigstellung meist sogar.

Auf der Poolseite ist die Verteilung wichtiger als die Anzahl. Zehn Adressen aus demselben Subnetz koennen sich hinsichtlich der Vielfalt wie eine einzige Adresse verhalten; drei ueber verschiedene Subnetze verteilte Adressen liefern bessere Ergebnisse (Subnetz-Vielfalt, Pool-Verwaltung). Pruefen Sie regelmaessig, ob die Adressen aktiv sind; ein toter Exit erzeugt im Bericht stillschweigend fehlende Zeilen.

Auch die Wiederverwendung von Verbindungen beeinflusst das Tempo. Bei jeder Abfrage einen neuen TCP- und TLS-Handshake durchzufuehren ist langsam und erzeugt zudem auf der Exit-Seite unnoetige Last; eine offene Verbindung zu halten verringert beides und erzeugt im selben Zeitraum ein weniger auffaelliges Muster. Beruecksichtigen Sie bei der Wahl der Zahl paralleler Streams die Obergrenze auf der Proxy-Seite (Limit gleichzeitiger Verbindungen); schon eine einzige Ergebnisseite kann davon mehr verbrauchen, als Sie erwarten.