Google Places Bulk Uploads, ein paar Erfahrungen und Tipps

ZOMFG, Richie tickert SEO-Kram, aber mit der Geschichte hatte ich in der letzten Zeit viel zu tun und ich dachte, vielleicht hilfts ein paar anderen, mir haben auch gelegentlich Leute geholfen und man gibt ja gern was zurück. So wirklich viele Leute da draussen werden wohl nicht mit Bulkdaten bei Google Places zu tun haben – Google Places ist diese Angabe zum Ort/Unternehmen, die einen schönen und durchaus ausführlichen Eintrag bei Google Maps ermöglicht. Damit spiel ich schon ein paar Jahre rum, Bulkfeeds hatte ich nun auch einige in der Hand und die braucht man dann, wenn man mehr als zehn Places anlegt/verwaltet/pflegt. Spätestens da macht es auch keinen Spass mehr, sich händisch um jeden einzelnen Place zu kümmern. Das fängt damit an, dass man Places einzeln via Postkarte oder SMS verifizieren (bestätigen, dass man der Eigentümer ist) muss, beim Bulk kann man das en bloc.

Wo legt mans an? Google Places.
Wo gibts Muster-Files? Hier, englisch. Es geht auch Deutsch, fragt grade nicht, wo das Muster liegt – Google macht beim .TSV-DL eh wieder englisch draus. Mehr zu .tsv folgt.
Infos zu optionalen Feldern, Feldformaten und Inhalten: hier.
Überhaupt: Hilfeseiten-Übersicht zu Places.
Ein freundliches Hilfeforum gibts auch (deutsch), und den
Places-Blog von Google (englisch).

Account anlegen und einrichten

Bei Google anmelden bzw. ein Google-Konto anlegen. Wenn man die Bulk-Geschichte für einen Kunden macht, empfiehlt sich sehr, für den Account eine Mailadresse mit der Kundendomain zu nehmen und mit dem Kunden abzusprechen, wer die auch abrufen und die Bestätigung der Eigentümerschaft übernehmen kann.
In der Google-Accountverwaltung Places auswählen. Will man mehr als 10 Standorte verwalten, dann gar nicht mit der automatischen Findefunktion des Hauptstandortes rumspielen, sondern gleich direkt zum Bulk Upload springen – denn besser ists allemal, alle Standorte gemeinsam zu verwalten und nicht mit Bulk- und nebenbei noch händisch angelegten Places anzufangen.

Datenformate und Encoding

Liest man die Foren, denkt man, die Daten selbst seien das häufigste Problem. In der Praxis scheint mir das Datenformat und das Encoding rein umständehalber mehr Ärger zu machen. Google selber ist freundlich und aufgeschlossen, geht es um die hochladbaren Formate, da nimmt man XLS, CSV, TXT und noch so ein paar, aber der Download macht das alles wieder zu ner Oneway-Geschichte: lädt man den aktuellen Bulk runter, kriegt man eine .tsv-Textdatei in UTF8 (wie .csv, nur eben „tab separated value“ – das Komma kann in den Feldern der Places-Daten auftreten.). Die .tsv Googles wiederum macht beim Öffnen gerne Sonderzeichenprobleme. Da man spätestens nach dem Download und dem Weiterbearbeiten einer .tsv entweder mit einer .tsv oder einem Konvertierungsproblem dasteht, rate ich zum Arbeiten mit der .tsv. Und vor allem zur Faustregel: nie, NIE! eine auf Google Places zu verarbeitende Datei mit irgendwas von Microsoft anfassen. Nicht mal dran denken. Man nehme einen vernünftigen Editor, sonst nichts. Ultraedit auf Win, Textmate oder Textwrangler auf dem Mac, diese Kategorie. Will irgendwer ein Excelsheet, so importiert man eine Kopie in Excel (hier der sicherste Weg: .tsv im Editor als .csv und in nem verträglichen ISO-Charset wie 8859-15 speichern, in Excel als .csv importieren, einziges Trennzeichen: Tab. Nicht Komma, nicht Semikolon) und fasst das Ergebnis nie wieder selbst im produktiven Einsatz an.

Was droht? fragt der Schachspieler. Die unvermeidlichen Encoding-Fehler bei Sonderzeichen, CR/LF-Probleme, automatische „Formaterkennung“, die irgendwelche Datenfelder umformatiert. Letzteres übrigens nicht beschränkt auf die einschlägigen Office-Produkte.

Die Alternative? Google Docs scheint zwar eine zwar sichere Wahl, wenn man in einigermaßen schön aufbereiteter Form mit google-generierten .tsv-Files hantieren will, aber auch Google Docs bietet beim Upload eben eine Konversion an, die kann man annehmen (sollte man machen, damit man ein Tabellensheet kriegt) oder nicht (dann kann man gleich den Editor nehmen). Konvertiert man, dann werden bestimmte Datenwerte auch in irgendwas konvertiert. Ich wurde zwischenrein mal leicht irre, weil irgendwoher ein enorm unpassendes 2011/12/18 in eine Nummernspalte kam und ich erst nicht wusste, woher. Google Docs war schuld, das 18-12 für ein Datum hielt.

Datenqualität

Trotzdem klagt Gott und die Welt in den Hilfeforen natürlich insbesondere darüber, dass Google den Feed nicht fressen will bzw. was beanstandet. Häufigster Grund in meinen Uploads: fehlende Hausnummern. Das klingt trivial bis dämlich, ists aber nicht unbedingt, denn wahrlich, ich sage euch: es ist kein reines Glück, wenn man Adressen in irgendwelchen Kuhdörfern hat, wo manche Straßen schlicht nicht benummert sind. Es lässt einen auch am Konzept „Einkaufszentrum“ alleine deswegen zweifeln, weil die einzelnen Adressen in Einkaufszentren gelegentlich eben nicht klassische Straße-Hausnummer-Konstrukte sind. Muss man das alles noch Google erklären, dann ist der Tag euer Freund. Hier gibt es zumindest zwei gute Nachrichten.
– Google Places ist erstaunlich menschlich. Sprich, es bestehen gute Chancen, dass ein echter Mensch antwortet, wenn man dem Helpdesk nach einem abgelehnten Datenfeed zurückmailt. Dieser Mensch gibt oft sogar erfreulich konkretes Feedback a la „Adresse Sowieso fehlt Angabe ixypsilon“.
– Auch das kann man noch oft vermeiden/selber lösen (denn auf die Antwort muss man immer warten, und solange kommt man ja nicht wirklich vorwärts). Der Trick: man lädt den Bulk hoch. Anschließend meldet Google (optimalerweise), dass der Feed fehlerlos ist und veröffentlicht werden kann. Unter der Angabe sieht man nochmals den Feed in einer Google Docs-sheetähnlichen Ansicht. Hier kann man „kritische Kandidaten“ unter den Adressen (oder wenn man die Zeit hat, alle) einfach noch mal ansehen und testen. Sprich, man wählt ein Feld der zu prüfenden Adresszeile aus und sieht dann im Maps-Ausschnitt rechts oben den Pin, wie ihn Google setzen würde. Hat man hier statt Map/Pin-Preview eine Fehlermeldung, dass der Pin nicht gesetzt werden kann, hat man mit ziemlicher Sicherheit einen Ablehnungsgrund erwischt, den man entsprechend schon vorab besser adressieren sollte.

Wenn man durch ist, veröffentlichen. Dadurch wird noch nichts veröffentlicht, sondern nur ggf. an die Bulk-Bestätigung weitergereicht.

…und die Veröffentlichung

Die kann sich ziehen. Dass man autorisierter Vertreter der Adressen sein sollte (bzw. das Places-Account,. mit dem man arbeitet), hatten wir eingangs, und dann sollten hier keine diesbezüglichen Probleme mehr auftreten. Man gibt den Eigentümer bzw. den Bevollmächtigten mit offizieller und nachprüfbarer Adresse/Telefonnumnmer an, Google meldet sich dort und verifiziert. Alles gut – außer eben der Warterei: auch bei okayem Feed kanns sein, dass einzelne Adressen noch tage- und wochenlang in der Warteschleife hängen. Das ist früher oder später durch, wenn nicht doch noch ein „Action required“ nachkommt irgendwann, aber mehr als Abwarten, regelmäßig reingucken, ob vielleicht nicht doch noch was beanstandet wurde und sich beherrschen, um nicht unnötig rumzunerven (Hey, es steht da! Es kann dann auch *wirklich* wie angekündigt zwei bis vier Wochen dauern) kann ich da auch nicht raten.

Generelles und prinzipielles

Google will mit Places eine extrem hohe Datenqualität. Daher: so exakt wie möglich arbeiten, sich auf die Daten beschränken und (zumindest vorerst) nicht rumtricksen – persönlich gehe ich davon aus, dass Google Places nach Datenqualität und -menge bevorzugt anzeigt, nicht nach Keyworddichte usw. Die 5 Kategorien, die man einem „Place“ zuordnen kann, geben hier ein wenig Spielraum, in die anderen Datenfelder gehört nur das, was verlangt wird und gut. A propos Kategorien: zumindest eine würde ich aus den Default-Nummerierungen von Google nehmen, die wird von Google sicher erkannt/zugeordnet, auch in Fremdsprachen.

Ansonsten ließ ich mir mehrfach sagen, dass Google da keine „Schrauben angezogen“ hätte (in einigen anderen Feed-Geschichten wurden die Ansprüche an die Datenqualität und -menge hochgesetzt), alleine, mir fehlt der Glaube. Ich habe schon Adressen beanstandet bekommen, die so bereits bei Places akzeptiert wurden und aktiv waren. Meine Privattheorie ist, dass da manches „Bestandsschutz“ hat, aber neu hochgeladen eben nicht mehr angenommen wird. Da kann man nun wild spekulieren, praxisrelevant ist daran aber eines auf jeden Fall: dass ein Places-Adressdatenset mal bei Google angenommen wurde, heisst nicht automatisch, dass es frisch hochgeladen/eingetragen auch heute wieder angenommen wird. Zumindest mal grob sichten und weiter zumindest mit der Möglichkeit einer Ablehnung/Nachkorrektur rechnen hilft beim Vermeiden von extrem auf Kante rutschenden Zeitplänen.

Zu guter Letzt, technisch: es lohnt das Bloglesen, es gibt immer ein paar Änderungen/Ergänzungen, die so noch nicht in die Standard-Hilfetexte eingegangen sind. Bilder-URLS via Bulk mithochladen geht beispielsweise auch schon seit einiger Zeit, das steht auch irgendwo, aber IIRC noch immer nicht in den Standard-Anleitungen und -Vorlagen.

Zu guter Letzt, persönlich: Ich mag Places. Es ist so ein klassisches Win-Win in Sachen Informationsverfügbarkeit, dazu eher ne Whitehatkiste, in der vor allem zählt, dass die Daten gut und insbesondere hilfreich und nützlich sind, und ich denke, es wird noch ne etwas wichtigere Zentrale für existierende und kommende Geolocation- und sonstige Geschichten – man setzt nicht aus Jux dermaßen hohe Ansprüche an Datenqualität. Das ganze ist natürlich weitgehend shop/verkaufsorientiert, aber eben deswegen auch eine der datenschutzdiskussionstechnischen Geschichten, die man weniger debattiert, sondern macht und wo man nicht X Bedenken wälzen muss. Außer eben dem „Mach ichs oder lass ichs.“ Sinn, Zweck, Nutzen, Möglichkeiten kann man ja noch Romane schreiben (bzw. haben andere schon gemacht), hier gings mir drum, zumindest mal die Tipps rauszugeben, auf die ich so noch nicht so sehr an anderer Stelle gestoßen bin.

Und zum Schluss: Danke für die ganzen Tipps, die ich bisher selber bekommen hab.