English
Deutsch
PolskiMatomo-Tracking-API: Serverseitige Hits, Pflichtparameter und die Fehler, die trotzdem 200 liefern
Inhalt
Matomo lässt sich ohne eine Zeile JavaScript füttern: eine einzige HTTP-Anfrage an matomo.php trägt einen Seitenaufruf, ein Ereignis oder ein Ziel. Damit ist sie der naheliegende Weg, um festzuhalten, was ein Browser nie sieht – eine im Backoffice bestätigte Bestellung, eine telefonisch gekündigte Mitgliedschaft, ein durchgelaufener Stapelauftrag.
Die Eigenschaft, die sie angenehm macht, ist zugleich die, die das Suchen nach Fehlern erschwert. Der Endpunkt antwortet auf fast jede Anfrage gleich: HTTP 200 und ein leeres Bild, ob der Treffer aufgezeichnet, stillschweigend verworfen oder der falschen Seite zugeschrieben wurde. Alles Folgende handelt davon, diese drei Fälle auseinanderzuhalten, ohne dass die Antwort etwas dazu sagt.
Was ein Treffer mindestens braucht
Drei Parameter entscheiden darüber, ob überhaupt etwas aufgezeichnet wird: idsite für die Seite, zu der der Treffer gehört, rec=1 als der Schalter, der aus einer Anfrage eine Aufzeichnung macht, und etwas, das den Treffer benennt – eine url, ein action_name oder beides. Ohne rec=1 wird die Anfrage genau wie zuvor beantwortet, und gespeichert wird nichts.
Alles Weitere ist in dem Sinne freiwillig, dass der Treffer auch ohne es überlebt, und selten freiwillig in dem Sinne, dass der Bericht brauchbar bleibt. Ein Treffer ohne Adresse erscheint namenlos in den Berichten – jene Art Eintrag, die Monate später auffällt und sich dann nicht mehr zuordnen lässt.
Die Besucherkennung entscheidet über alles Weitere
Der Parameter _id ist eine Besucherkennung aus genau sechzehn Hexzeichen. Nicht fünfzehn, keine UUID mit ihren Bindestrichen, nicht die zweiunddreißig Zeichen eines MD5-Hashes – was das Format verfehlt, übergeht Matomo stillschweigend, und auf dem Stillschweigen liegt die Betonung.
Was dann geschieht, ist schlimmer als ein Fehler. Ohne brauchbare _id leitet Matomo den Besucher aus IP-Adresse und Browserkennung ab, was im Browser leidlich funktioniert und auf einem Server zusammenbricht: jeder Treffer kommt von derselben Adresse mit derselben Kennung, der Verkehr eines ganzen Tages verschmilzt also zu einem einzigen Besucher mit bemerkenswert vielen Aktionen.
Erkennbar ist das an einem Bericht, in dem ein Besucher den größten Teil der Ereignisse auf sich vereint, während die Zahl der Besuche flach bleibt. Das ist kein Bot, sondern ein Stapelauftrag ohne Kennung.
Custom Dimensions sind nur Nummern
Dimensionen werden als dimension1, dimension2 und so weiter übergeben, und die Nummer ist keine Bezeichnung – sie verweist auf einen Platz, den es in der Oberfläche von Matomo geben muss, bevor etwas hineingeschrieben werden kann. Ein Wert an eine nicht eingerichtete Nummer wird angenommen und verworfen.
Das zweite, was zu treffen ist, ist der Geltungsbereich. Eine Dimension mit Besuchsbereich hält einen Wert je Besuch und wird von jedem späteren Treffer überschrieben, der sie trägt; eine mit Aktionsbereich hält einen Wert je Aktion. Ein Tarifname im falschen Bereich ergibt entweder einen Wert, der sich mit dem letzten Seitenaufruf ändert, oder einen, der sich nicht als Segment über den Besuch verwenden lässt.
Was nur ein Server senden darf
Eine Handvoll Parameter verändert Daten, die eine Anfrage normalerweise nicht anfassen darf: cip für die echte IP-Adresse des Besuchers, cdt für einen anderen Zeitpunkt als jetzt, dazu die geografischen Felder. Alle verlangen token_auth, cdt allerdings erst für Zeitpunkte, die mehr als 24 Stunden zurückliegen. Fehlt das Token, wo es verlangt ist, lehnt Matomo die ganze Anfrage mit HTTP 400 ab.
Das Token gehört auf einen Server und sonst nirgendwohin. Im Browser liest es jeder Besucher mit, und es gewährt kein Lese-, sondern ein Schreibrecht: wer es besitzt, schreibt beliebige Treffer in die Statistik, und hinterher sind sie nicht mehr von den echten zu unterscheiden. Wo eine Seite selbst Treffer senden muss, sendet sie diese Parameter eben nicht mit.
Mit Token nimmt Matomo auch ältere Zeitpunkte an, solange sie nicht vor der eingestellten Löschfrist für Rohdaten liegen. Eine Woche Geschichte lässt sich deshalb mit cdt nachtragen; die Berichte der betroffenen Tage müssen danach allerdings neu verarbeitet werden.
Warum ein Treffer lautlos verschwindet
| Ursache | Was zu sehen ist |
|---|---|
Fehlendes rec=1 |
Überhaupt nichts, und die Anfrage sieht völlig gewöhnlich aus. |
Falsche idsite |
Die Treffer landen in der Seite, die diese Nummer trägt; gibt es sie nicht, antwortet Matomo mit HTTP 400. |
_id im falschen Format |
Alle Treffer verschmelzen zu einem Besucher, die Zahl der Besuche steigt nicht mehr. |
cdt ohne Token |
Bis 24 Stunden zurück wird der Treffer mit dem gemeinten Zeitpunkt aufgezeichnet; ältere Zeitpunkte lehnt Matomo mit HTTP 400 ab. |
| Nicht eingerichtete Dimension | Der Treffer wird aufgezeichnet, die Dimension nicht. |
Die Prüfung, die das meiste davon in einer Minute beendet, ist das Besucherprotokoll mit geöffneter Echtzeitansicht, während die Anfrage abgeht. Ein Treffer, der dort erscheint, ist aufgezeichnet; einer, der ausbleibt, wurde verworfen, und die Liste oben sagt, wo zu suchen ist. Die Antwort wird es nie tun.
Fragen und Antworten
Woher bekommt ein Server eine gültige _id, wenn derselbe Besucher auch im Browser gezählt wird?
Am besten vom Browser selbst. Der JavaScript-Tracker von Matomo legt die Besucherkennung in einem Cookie ab, dessen Name mit _pk_id beginnt; sein Wert fängt mit genau den sechzehn Hexzeichen an, die _id erwartet, gefolgt von einem Punkt und weiteren Angaben. Kommt die Anfrage, die den serverseitigen Treffer auslöst, aus diesem Browser, lässt sich die Kennung dort auslesen und mitsenden. Browser- und Servertreffer landen dann beim selben Besucher.
Fehlt dieser Weg, etwa bei einer telefonisch gekündigten Mitgliedschaft, genügt eine eigene, stabile Kennung im richtigen Format. Eine übliche Lösung sind die ersten sechzehn Hexzeichen eines Hashes der Kundennummer; der vollständige MD5-Hash mit zweiunddreißig Zeichen würde verworfen. Dieselbe Person erhält so bei jedem Treffer dieselbe Kennung, ohne dass die Kundennummer selbst in Matomo steht.
Zwei Punkte gehören dazu. Ein solcher Hash bleibt ein Pseudonym und damit ein personenbezogenes Datum, und das Auslesen des Cookies setzt voraus, dass der Browser-Tracker überhaupt eines setzen durfte. Ohne Einwilligung oder bei cookieloser Messung gibt es dort nichts zu lesen.
Warum zeigen serverseitige Treffer alle denselben Standort?
Weil Matomo ohne cip die Adresse der Anfrage nimmt, und das ist die des sendenden Servers. Die Standortberichte zeigen dann das Rechenzentrum, in dem der Stapelauftrag läuft. Die echte Besucheradresse lässt sich nur mit cip übergeben und damit nur zusammen mit token_auth.
Passend dazu
