Schlagwort: google

Veröffentlicht am

Google Optimize hacken: Von Bayes, p-Werten, A/A-Tests und vergessenen Metriken

Google Optimize ist eines meiner Lieblings-Tools, denn es ermöglicht jedem schnell a/b-Tests zu bauen; in meinen Kursen staunen die Teilnehmer häufig, wie schnell so ein Test online sein kann. Natürlich ist die Vorarbeit, das saubere Erstellen einer Hypothese, nicht so schnell getan, aber es macht auch keinen Spaß, monatelang auf die Live-Schaltung eines Tests zu warten. Über die Vorzüge von Google Optimize will ich auch gar nicht weiter eingehen, sondern stattdessen auf drei Feinheiten hinweisen, die nicht so offensichtlich sind.

Google-Optimize-Daten in Google Analytics Rohdaten verwenden

Die Google Analytics API erlaubt auch den Zugriff auf Google Optimize-Daten, die in Analytics reinlaufen, was ermöglicht, dass die Analytics-Rohdaten zu einem Google Optimize-Test analysiert werden können. Das ist vor allem dann interessant, wenn etwas nicht als KPI in Optimize verwendet werden kann, man in Google Optimize vergessen hat, einen KPI einzustellen oder Nebeneffekte analysiert werden sollen. Einiges davon geht auch hinterher mit Segmenten, aber hey, hier geht es ums Hacken (im Sinne von Tüftler, nicht Krimineller), da macht man auch Dinge, weil man sie machen kann, nicht weil sie immer notwendig sind

Die beiden wichtigen Optimize-Dimensionen heißen ga:experimentId und ga:experimentVariant, mittlerweile existiert auch eine Kombination, die ga:experimentCombination heißt. Wobei, wenn man nur einen Test fährt, dann reicht es auch, nur die Dimension ga:experimentVariant abzufragen. 0 ist die Originalvariante (Kontrollgruppe), danach wird pro Variante hochgezählt. Hat man mehrere Tests am laufen, so einfach in der Google Optimize-Oberfläche die ID nachschauen; sie findet sich in der rechten Spalte unter Google Analytics. Sie ist meistens sehr kryptisch, wie man auf dem Bild sehen kann.

In meinem Beispiel habe ich zwei Experimente am Laufen, so dass ich mir die Kombination ausgeben lasse neben drei Custom Dimensions (Client ID, Hit Type und UNIX Timestamp) sowie Seitentitel (die Client ID hab ich auf dem Bild etwas abgeschnitten, da es ja nur ein pseudonymisiertes Datum ist). Wir sehen auf dem zweiten Bild die beiden Experimente und die jeweiligen Varianten in einem Feld. In dem Test, der mit c-M startet, hatte ein Kursteilnehmer die Hypothese aufgestellt, dass die Besucher meiner Seite mehr Seiten ansähen und mehr Zeit verbrächten, wenn das Suchfenster weiter oben wäre. Ich habe nicht daran geglaubt, aber Glauben ist nicht Wissen, also haben wir den Test gefahren mit dem KPI Session Duration. Vergessen hatte ich hier, die Anzahl der Suchen als zweiten KPI einzustellen. Nun gut, dass ich die Rohdaten habe, auch wenn ich dafür natürlich auch ein Segment bauen könnte.

Wie wir in dem Screenshot auch sehen können, sind die Nutzer gleichzeitig in zwei Tests, da der andere Test keinen Einfluss auf den ersten Test haben sollte. Nun gab es während der Test-Laufzeit von 4 Wochen auf meiner Seite nur 3 Nutzer, die nach etwas gesucht haben, einer der Nutzer hat eine Query mehrmals gesucht, ein Nutzer hat zwei verschiedene Terme gesucht. Bei einer so geringen Fallzahl brauchen wir erst gar nicht über Signifikanz nachdenken. Zwischenzeitlich sah es mal so aus, als würde tatsächlich die Suchfenster oben-Variante gewinnen, aber dazu im letzten Abschnitt mehr. Die Frage ist nun, warum überhaupt die Variante besser sein kann, wenn doch kaum gesucht wurde? Oder hat allein die Präsenz der Suchbox zu einer längeren Session Duration geführt? Sehr unwahrscheinlich!

Das sollten wir uns einmal genauer anschauen…

Zu beachten ist in den Rohdaten, dass es nun für jeden Hit eines Nutzers zwei Einträge gibt, einen pro Test. Außerdem wird nicht jeder Nutzer in einem Test sein, auch wenn 100% des Traffics getargeted sind, was man aber auch schon in Google Analytics sehen kann. Ebenso können wir überprüfen, ob durch die zufällige Auswahl von Test- und Kontrolgruppenteilnehmern eine einigermaßen gleichmäßige Aufteilung der Nutzer erfolgt ist (z.B. Mobile versus Desktop etc). Auch das ist natürlich mit dem Interface möglich.

Das erste, was auffällt, wenn ich die Daten aus der API ziehe, ist, dass die Werte nicht mit denen aus der GUI übereinstimmen. Das ist zunächst einmal ziemlich beunruhigend. Schaue ich mir nur Users und Sessions an, so stimmen die Werte genau überein. Nehme ich die Dimension experimentCombination hinzu, so passen die Zahlen nicht mehr, und es liegt nicht an den Unterschieden zwischen API v3 und v4. Es ist nicht ungewöhnlich, dass die Daten nicht zusammen passen, meistens geschieht das durch Sampling, aber das kann hier nicht der Fall sein. Interessanterweise stimmen auch die Zahlen innerhalb der GUI nicht überein, wenn ich mir die Daten unter Experiments ansehe und sie mit dem Dashboard zur Zielgruppe vergleiche. Die Zahlen aus der API stimmen aber mit den Daten aus dem Experiments-Bericht überein. Vorsicht also wer Segmente bildet!

Ziehe ich die Daten inklusive meiner ClientID-Dimension, so habe ich etwas weniger Users, was sich dadurch erklärt, dass nicht jeder User eine solche ID in die Custom Dimension reinschreibt, d.h. er hat diese Client ID wahrscheinlich (oder sicherlich, denn sonst könnte GA ihn nicht als einzelnen Nutzer identifizieren), aber ich schaffe es irgendwie nicht die ID in die Dimension zu schreiben, so dass dort zB “False” steht.

Nun schauen wir uns einmal ein paar Daten an. Mich interessiert zum Beispiel, ob Optimize es schafft, die gleiche Verteilung über Devices hinzubekommen wie ich sie auf der Seite habe:

Der Großteil meines Traffics findet noch auf dem Desktop statt. Wie sieht es in Optimize aus?

Die Verteilung ist definitiv eine andere. Das ist auch wenig verwundertlich, denn auf AMP-Seiten sollte kein Optimize-Experiment ausgespielt werden; es ist also eher verwunderlich, warum hier überhaupt noch Experimente auf Mobilgeräten stattgefunden haben. Und diese Fälle haben andere Werte in Bezug auf den Ziel-KPI, wie man auch in Analytics sehen kann:

Wir können also nicht von den Testergebnissen auf die ganze Seite schließen, wir wissen aber auch nicht, wie groß der Effekt der unerwarteten Mobile-User auf das Testergebnis ist. Hierzu müssten wir also den Gewinner neu ermitteln. Doch wie wird der Gewinner überhaupt ermittelt? Wir könnten zum Beispiel einen Chi-Square-Test verwenden mit der Beobachtung der durchschnittlichen SessionDuration:

chisq.test(x) Pearson’s Chi-squared test with Yates‘ continuity correction data: x X-squared = 1.5037, df = 1, p-value = 0.2201`

In diesem Fall ist p über 0.05, zu p im nächsten Abschnitt mehr. Sollte der Chi-Square-Test überhaupt der richtige Test sein, so ergäbe er, dass der Unterschied nicht statistisch signifikant ist. Allerdings ist das nicht der Test, den Google Optimize verwendet.

Bayessche Inferenz versus NHST

Was passiert da eigentlich genau unter der Motorhaube? Schauen wir uns an, wie Google Optimize berechnet, ob eine Variante gewonnen hat oder nicht. Im Gegensatz zu Adobe Test & Target zum Beispiel oder den meisten Signifikanzrechnern wie dem von Konversionskraft (wobei Konversionskraft nicht mal sagt, was für einen Test sie nutzen), basiert Google Optimize nicht auf einem t-Test, Mann-Whitney-U- oder Chi Square-Test, sondern auf einem Bayes-Inferenz-Verfahren. Was bedeutet das?

Hier treffen zwei unterschiedliche Vorstellungen aufeinander, die der sogenannten Frequentists (NHST steht für Null Hypothesis Significance Testing) und die der Bayesschen Inferenz-Anhänger. Diese wurden und werden zum Teil immer noch in der Statistik intensiv diskutiert, und ich bin nicht der Richtige, um hier ein Urteil zu fällen. Aber ich versuche, diese beiden Ansätze für Nicht-Statistiker zu beleuchten.

In den meisten A/B-Test-Tools werden Hypothesen-Tests durchgeführt. Man hat zwei Gruppen von ungefähr gleicher Größe, die eine Gruppe wird einem “Treatment” ausgesetzt, und dann wird beobachtet, ob sich der definierte KPI in der Testgruppe “signifikant” ändert. Für Signifikanz wird meistens auf den p-Wert geschaut; sofern dieser unter 0,05 liegt oder wie auch immer das Signifikanz-Niveau definiert wurde, wird die Null-Hypothese abgelehnt. Zwar sieht man auf den Tool-Oberflächen nichts von Null-Hypothesen etc, wahrscheinlich um die Nutzer nicht zu verwirren, aber das Denkkonstrukt dahinter geht davon aus. Wird zum Beispiel getestet, ob ein roter Button häufiger angeklickt wird als ein blauer, so würde die Null-Hypothese lauten, dass beide gleich häufig angeklickt werden. Der Hintergrund davon ist, dass sich eine Hypothese nicht immer belegen lässt. Wenn aber das Gegenteil der Hypothese eher unwahrscheinlich ist, so kann angenommen werden, dass eine Hypothese eher wahrscheinlich ist. Von nichts anderem handelt der p-Wert.

Nun ist der p-Wert keine einfache Geschichte, nicht einmal Wissenschaftler schaffen es, den p-Wert so zu erklären, dass es verständlich ist, und es wird diskutiert, ob er überhaupt sinnvoll ist. Der p-Wert sagt nichts darüber aus, wie “wahr” ein Testergebnis ist. Er sagt lediglich etwas darüber aus, wie wahrscheinlich es ist, dass dieses Ergebnis auftritt, wenn die Null-Hypothese wahr ist. Bei einem p-Wert von 0,03 bedeutet das also, dass die Wahrscheinlichkeit, dass ein Ergebnis auftritt bei einer wahren Null-Hypothese, bei 3% liegt. Das bedeutet umgekehrt nicht, wie “wahr” die Alternative Hypothese ist. Der umgekehrte p-Wert (97%) bedeutet also nicht eine Wahrscheinlichkeit, dass eine Variante eine andere Variante schlägt.

Ein häufiges Problem mit a/b-Tests ist zudem, dass die Sample-Größe nicht vorher definiert wird. Der p-Wert kann sich über die Laufzeit eines Experiments ändern, und so können statistisch signifikante Ergebnisse nach ein paar Tagen schon nicht mehr signifikant sein, da sich die Anzahl der Fälle geändert hat. Außerdem interessiert nicht nur die Signifikanz, sondern auch die Stärke/Trennschärfe/Power eines Tests, die nur in den wenigsten Test-Tools angezeigt wird.

Das sind aber vor allem Probleme der Tools, nicht des Frequentists-Ansatzes, der von den meisten Tools genutzt wird. Das “Problem” des Frequentists-Ansatzes ist, dass sich ein Modell nicht ändert, wenn neue Daten hereinkommen. So kann bei wiederkehrenden Besuchern eine Änderung auf der Seite irgendwann gelernt werden, so dass ein anfänglicher a/b-Test zwar große Wirkung prophezeit, die tatsächliche Wirkung aber viel geringer ist, weil im Frequentists-Ansatz einfach nur die Gesamtzahl von Conversions gezählt wird, nicht die Entwicklung. In der Bayesschen Inferenz werden neu hereinkommende Daten aber berücksichtigt, um das Modell zu verfeinern; geringer werdende Conversion-Raten würden das Modell beeinflussen. Daten, die sozusagen “vorher” vorhanden sind und die Annahmen über den Einfluss in einem Experiment beeinflussen, werden Anfangswahrscheinlichkeit oder “Priors” genannt (ich schreibe Priors, weils schneller geht). Das Beispiel in der Google-Hilfe (das auch anderswo gerne bemüht wird), ist, dass, wenn man sein Handy im Haus verlegt, nach der Bayesschen Inferenz das Wissen, dass man sein Handy gerne mal im Schlafzimmer vergisst, verwenden und auch einem Klingeln “hinterherlaufen” darf. Bei den Frequentists darf man das nicht.

Und hier genau tut sich das Problem auf: Woher wissen wir, dass die “Priors” relevant sind für unsere aktuelle Fragestellung? Oder, wie es im Optimizely-Blog gesagt wird:

The prior information you have today may not be equally applicable in the future.

Die spannende Frage ist nun, wie Google in Optimize auf die Priors kommt? Dazu wird folgende Aussage gemacht:

Despite the nomenclature, however, priors don’t necessarily come from previous data; they’re simply used as logical inputs into our modeling.

Many of the priors we use are uninformative – in other words, they don’t affect the results much. We use uninformative priors for conversion rates, for example, because we don’t assume that we know how a new variant is going to perform before we’ve seen any data for it.

An diesen beiden Blogauszügen wird schon deutlich, wie unterschiedlich das Verständnis von der Nützlichkeit der Bayesschen Inferenz ist Gleichzeitig ist offensichtlich, dass uns wie in jedem anderen Tool auch Transparenz darüber fehlt, wie genau die Berechnungen zustande gekommen sind. Ein weiterer Grund, dass man, wenn man auf Nummer sicher gehen will, die Rohdaten benötigt, um eigene Tests durchzuführen.

Der Bayes-Ansatz erfordert mehr Rechenzeit, was wahrscheinlich der Grund dafür ist, dass die meisten Tools nicht diesen Ansatz nutzen. Es existiert auch Kritik an der Bayes-Inferenz. Das Hauptproblem aber ist, dass die meisten Nutzer viel zu wenig wissen von dem, was genau die a/b-Test-Tools tun und wie belastbar die Ergebnisse sind.

Warum ein A/A-Test auch heilsam sein kann

Nun stellt sich die Frage, warum überhaupt ein Unterschied sichtbar war bei der Session Duration, wenn doch kaum jemand gesucht hat. Hier kann ein A/A-Test helfen. A/A-Test? Richtig gelesen. Auch sowas gibt es. Und ein solcher Test hilft dabei, die Varianz der eigenen Seite zu identifizieren. So hatte ich einen wunderbaren Test, bei dem ich die AdSense-Klickrate nach einer Design-Änderung getestet hatte. Die Änderung war sehr erfolgreich. Um ganz sicher zu gehen habe ich noch mal getestet; dieses Mal hatte die Änderung schlechtere Werte. Nun kann es natürlich sein, dass einfach schlechtere Ads geschaltet wurden und sich deswegen die Klickrate verschlechtert hatte. Es könnte aber auch einfach sein, dass die Seite selber eine Varianz hat. Und diese kann man herausfinden, indem man einen A/A-Test fährt (oder die vergangenen Rohdaten für einen solchen Test nutzt). Bei so einem Test wird in der Test-Variante einfach nichts geändert und dann geschaut, ob sich einer der Haupt-KPIs ändert oder nicht. Rein theoretisch sollte sich nichts ändern. Aber wenn doch? Dann habe wir eine Varianz identifiziert, die in der Seite und dem Traffic selbst liegt. Und die wir in zukünftigen Tests berücksichtigen sollten.

Fazit

  • Unterschiede in Test-Ergebnissen können durch eine bereits bestehende Varianz einer Seite zustande kommen. Hier hilft ein A/A-Test, um die Varianz kennen zu lernen.
  • Die Ergebnisse können sich unterscheiden, wenn unterschiedliche Tools eingesetzt werden, da die Tools unterschiedliche Herangehensweisen haben, wie sie die “Gewinner” ermitteln.
  • Rohdaten können helfen, eigene Test-Statistiken zu verwenden oder Test-Ergebnisse zu verifizieren, da die Tools wenig Transparenz darüber bieten, wie sie zu den jeweiligen Tests gekommen sind. So kann es zum Beispiel wie in meinem Beispiel sein, dass der Test gar nicht gleichmäßig ausgespielt wurde und daher die Ergebnisse nicht so eindeutig verwendbar sind.
  • Die Rohdaten unterscheiden sich zum Teil stark von den Werten in der GUI, was nicht erklärbar ist.
  • Der p-Wert ist nur ein Teil der Wahrheit und wird häufig missverstanden.
  • Bei a/b-Tests sollte man sich bei den Frequentists-Ansätzen vorher überlegen, wie groß die Sample-Größe sein sollte.
  • A fool with a tool is still a fool.
Veröffentlicht am

Google Wifi im Netzwerk mit SONOS, FritzBox & Synology NAS

Update Juli 2019: Ich habe die Google Wifi Pucks wieder in Rente geschickt, da sie den Langzeittest nicht bestanden haben. Die neue Installation läuft mit einem Netgear Orbi.

Zwar ist unsere Wohnung zumindest gefühlt nicht soooo groß, aber der FritzBox 6490 Kabel-Router allein war zu schwach auf der Brust für die ganze Wohnung; kein Wunder, steht er auch in der äußersten Ecke der Wohnung und nicht zentral. Zunächst ergänzte ein AVM Fritzbox Repeater 310 das WLAN, mangels 5 GHz wurde dieser durch das Modell 1750 ersetzt. Das funktionierte ganz ok, aber so richtig reibungslos eben auch nicht. Nicht selten ertappte man den Repeater mit blinkenden LEDs, bis ins Bad reichte der WLAN-Empfang oft nicht, und dann gabs immer wieder Aussetzer, die ich mir einfach nicht erklären konnte. Nach den überwiegend positiven Berichten sollte ein Google Wifi die Probleme lösen.

Google Wifi Mesh versus Extender/Repeater

In der Hoffnung, dass eine Station reicht, so klang zumindest die Werbung, ignorierte ich das Doppelpack und kaufte lediglich eine Komponente. Gleich vorweg, das reicht nicht, zumindest nicht wenn das Gerät in einer Ecke der 120qm-Wohnung steht. Weniger Geräte als vorher habe ich jetzt schon mal nicht, und mit 130-140€ pro Gerät ist die Kombi eine teurere Alternative. Aber die Vorzüge des Mesh-Netzwerks sowie die Aussicht, Ruhe zu haben mit den ständigen Netzwerkproblemen, war mir den Test wert. Nichts ist so nervig wie ein stockender Film, weil irgendeine Komponente im Netzwerk gerade ein Problem hat. Und für die Einrichtung des Repeaters inklusive eines Gast-Modus sind mehrere Stunden und viele Support-Mails draufgegangen.

Ein Repeater hat den Nachteil, dass er das Signal eines WLANs einfach verlängert, dafür aber etwas von der Geschwindigkeit verloren gehen kann, weil ein Overhead in der Kommunikation entsteht. Vermaschte Netze hingegen haben dieses Problem nicht, sie sind einfach EIN Netzwerk; neben dem 2,4 GHz und dem 5 GHz-Netz haben sie ein drittes Funkmodul, über das die Geräte miteinander kommunizieren. Man wechselt also auch nicht von dem Bereich des Haupt-WIFIs in das des Repeaters, sondern befindet sich die ganze Zeit in einem Netzwerk.

Die Einrichtung des Google Wifi

Die Einrichtung ist supereinfach, die App führt durch das Setup, innerhalb von zehn Minuten ist man startklar. Dabei wird die aktuellste Softwareversion des Google Wifi runtergeladen, was den Löwenanteil der Zeit ausmacht. Ehrlich gesagt hatte ich mehr Zeit damit verbraten, die Packung aufzubekommen, was vor allem an meiner Unfähigkeit liegt, Tesastreifen zu erkennen und abzupulen.

Nachdem die App meldete, dass mein Google Wifi nun fertig ist, stellte ich das WLAN des Fritzbox Routers aus und stellte die Verbindung auf mein neues WLAN um. Das Einrichten und das Konfigurieren des WLANs sind wirklich ein Kinderspiel, nur meine Sonos-Anlage wollte hinterher nicht mehr funktionieren, dazu unten mehr. Es macht Spaß, die App zu nutzen, die Internetverbindung und die WLAN-Geschwindigkeit in jedem Raum per Knopfdruck zu testen. Ein Gast-WLAN ist sehr einfach eingerichtet. Was mir fehlt, aber das fehlt mir nicht nur hier, ist eine einfache Möglichkeit, einem Gerät weniger Geschwindigkeit zuzuordnen, denn wenn die Synology NAS mal loslegt mit dem Backup in die Cloud, dann wird das ganze Netz lahm (siehe dazu auch den Artikel, wie man bei einer Synology NAS die Upload-Geschwindigkeit reduziert).

Erst nach 2 Wochen übrigens habe ich gemerkt, dass ich den Google Wifi-Puck in eine LAN-Buchse der FritzBox eingestöpselt hatte, die “nur” auf 100 Mbit/s eingestellt war. Da wir von Vodafone netterweise 200 Mbit/s geschenkt bekommen haben für ein paar Monate, hab ich unser WLAN also selbst ausgebremst. Nicht dass das groß aufgefallen wäre, der limitierende Faktor ist bei uns eh die Upload-Geschwindigkeit. Aber so kam ich in den Tests von 91 Mbit/s auf 189 Mbit/s. Von den 212 Mbit/s, die die FritzBox meldet, gehen irgendwo 23 Mbit flöten, aber mal ganz ehrlich: Wer früher mit einem 56K-Modem durchs Netz surfte, wird sich hier erst beschweren, wenn das tatsächlich mal ein Problem werden sollte. Eine über 3.400 Mal schnellere Internetverbindung geht zwar auch einher mit viel beladeneren Internetseiten und Filmen, aber das ist eine andere Geschichte.

Nicht ganz einfach ist die Einrichtung von IPv6, was aber nicht an Google Wifi liegt, sondern an der Fritzbox. Die Standardeinstellungen hier sehen so aus, als wäre IPv6 kein Problem, allerdings sind zusätzliche Einstellungen notwendig. Zum Beispiel bei “Auch IPv6-Präfixe zulassen, die andere IPv6-Router im Heimnetzwerk bekanntgeben” und bei “DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen”. Dann sagt Google Wifi zwar nicht, dass es funktioniert, aber dass der ISP es eventuell nicht unterstützt. Tut er in meinem Fall aber

Aber wie schon in der Einleitung angekündigt: Das WIFI reichte wenn überhaupt nur mit schwacher Verbindung in das andere Ende der Wohnung. Ganz abgesehen davon hoffe ich damit auch mein SONOS-Problem zu lösen, denn die Verbindung zu Spotify brach immer wieder ab.

Hinzufügen eines weiteren Google Wifi Knotens: Probleme mit iOS

Also rein in den Mediamarkt, ein zweites Google Wifi gekauft (jaja, der Doppelpack wäre dann doch günstiger gewesen), und schnell zuhause angeschlossen. Genau so einfach wie beim ersten Gerät ist die Einrichtung, hier die Ergänzung des Netzwerks, nur eine Sache hat mich gestört: Wenn ich bei der Installation des ersten Google Wifi schon eingewilligt habe, Kaufanreize und Statistiken zu meinem Netzwerk von Google zu erhalten, warum werde ich dann beim zweiten Gerät noch mal gefragt? Wenn ich jetzt “Nein” sage, bekomme ich dann auch die Mails für das erste Gerät nicht mehr?

Dann der Nervkram: Aus irgendeinem Grund streikte mein iPhone nach der Einrichtung des zweiten Knotens und wollte partout nicht mehr ins Netz, während mein Macbook sich problemlos verbinden konnte. Netzwerkeinstellungen zurückgesetzt, Netzwerk ignoriert, alles versucht, und trotzdem streikte das iPhone (und das iPad solidarisch mit). Dumm nur, wenn darauf die Google Wifi App installiert ist und man also ohne Internetzugang nicht mehr auf die Google Wifi-Konfiguration zugreifen kann Denn eine Konfigurationsmöglichkeit vom Rechner besteht nicht, es funktionieren nur Apps. Schnell das alte Android-Handy ausgegraben, sich über 50 Update-Wünsche gewundert, und dann schnell die Google Wifi-App runtergeladen. Alles kein Problem. Das Netzwerk lief. Warum wollten iPhone und iPad nicht mehr in das Google Wifi?

Nach einer halben Stunde kam ich auf die Idee, mir einmal die IP-Adresse, die Router-Adresse sowie die DNS-Server anzusehen, die sich das iPhone und das iPad gezogen hatten. Der Fehler lag darin, dass der DNS-Server die gleiche IP hatte wie der Router, in diesem Fall die 192.168.86.1. Ich weiß nicht, ob diese schon vorher drin stand, aber es funktionierte auf jeden Fall nicht. In der Google Wifi-App war “DNS des ISP” festgelegt, anscheinend klappte es aber nicht. Also unter den iPhone-Einstellungen einen anderen DNS-Server eingegeben, und schon funktionierte es wieder. Googles DNS-Server 8.8.8.8 kann man sich ganz gut merken, ich empfehle FreeDNS (37.235.1.174 und 37.235.1.177), da hier nicht protokolliert oder umgeleitet wird. Bisher habe ich keinen Unterschied zu Googles schnellen DNS-Servern entdeckt. Das Problem bei diesem Ansatz ist allerdings, dass man dann mit der App nicht mehr alle Einstellungen vornehmen kann, denn auch wenn man mit dem Google Wifi verbunden ist, lautet die Fehlermeldung, dass man sich doch mit dem Wifi verbinden solle.

SONOS und Google Wifi

Kommen wir nun zum SONOS. Zunächst hatte ich dem Google Wifi den gleichen Namen gegeben wie meinem alten WLAN, in der Hoffnung, dass ich dann ansonsten nirgendwo etwas ändern müsste. Das hat dann schon mal nicht funktioniert. Dann fiel mir ein, dass ja ein SONOS-Gerät mit einem Ethernet-Kabel mit dem Router verbunden ist, um die Vorteile eines BOOST-Setups zu haben (Unabhängigkeit vom WLAN des Routers). Tatsächlich befindet sich das Google Wifi aber in einem anderen Netzwerk, d.h. es vergibt eigene IP-Adressen an die angeschlossenen Geräte. Vergibt der Fritzbox-Router alles im 192.168.178.x-Netzwerk, ist das Google Wifi mit 192.168.86.x unterwegs. Das Google Wifi-Gerät bietet einen LAN-Anschluss, meine Fritzbox 4, wo neben dem SONOS auch noch die Synology und ein Arlo drinstecken. Das Arlo ist egal, aber die Synology und SONOS sollten im gleichen Netzwerk sein. Natürlich könnte man das Google Wifi auch im Bridge-Modus verwenden (und somit die IPs der Fritzbox verwenden und im gleichen Netzwerk sein), aber dann kann man kein Mesh-Netzwerk mehr aufbauen. Kommt also nicht in Frage.

Abhilfe sollte schaffen, die SONOS-Anlage von BOOST auf Standard-Setup umzukonfigurieren. Das ist nicht ganz so einfach, wie es sich anhört, denn erst mal muss mindestens ein SONOS-Gerät via Ethernet in die Google Wifi. Um es kurz zu machen: Ein unterbrechungsfreies Abspielen von Musik war nur von der lokalen Musikbibliothek möglich, nicht von Spotify oder Soundcloud. Ich vermutete, dass das vor allem daran liegt, dass das WLAN nicht in die hintersten Räume reicht. An der LAN-Buchse des Google Wifi hing meine Synology NAS, die ich nicht bereit bin, immer wieder gegen SONOS zu tauchen, also muss entweder ein Switch her… oder eben ein zweites Google Wifi, was ich ja gekauft habe. Ein SONOS-Gerät in das zweite Google Wifi, wieder auf BOOST umgestellt, und schon… funktionierte es nicht. Angeblich stellt sich ja das SONOS-System automatisch auf BOOST um, sobald ein Gerät mit Ethernet an das WLAN verbunden wird, aber dennoch muss man noch unter den Erweiterten Einstellungen das Wireless Netzwerk neu einrichten. Und dann klappte es auch ohne Probleme mit Spotify. Ich frage mich, warum das noch notwendig ist, denn schließlich wird im BOOST-Modus ein eigenes Netzwerk für die SONOS-Geräte erstellt. Dass ich im BOOST-Modus bin, sagt zumindest die Controller App.

Google Wifi und Synology NAS

Richtig problematisch wird es aber dann mit der Synology NAS. Diese soll ja auch weiterhin von außen erreichbar sein. Und hier wirds nun schwierig. Denn dadurch, dass die NAS nun am Google Wifi hängt, kann sie nicht mehr so einfach via DDNS angesprochen werden. Der QuickConnect-Link aber geht seltsamerweise noch. Hier habe ich noch keine Lösung gefunden…

Fazit

Die Einrichtung ist wahrscheinlich die einfachste Setup-Prozedur, die ich jemals bei einem Wifi-Gerät gesehen habe. Das Netzwerk wirkt zuverlässiger, wenngleich die aufgetretenen Probleme von einem Normalo-Nutzer wahrscheinlich nicht hätten gelöst werden können. Der Langzeittest erst wird verraten, wie zuverlässig dieses neue Netz wirklich ist. Je weniger Beschwerden von der Familie kommen, desto mehr war der Tausch das Geld wert