Viele Unternehmen betreiben eine Website und eine mobile App, messen sie mit zwei verschiedenen Werkzeugen und stellen fest, dass die beiden nie über irgendetwas einig sind. Die übliche Antwort ist, die Zahl zu nehmen, die das gerade geführte Argument stützt. Hier ist, was tatsächlich schiefgeht, und was auf ein Werkzeug zutreffen muss, damit es beide abdeckt, ohne Sie anzulügen.

Die vier Dinge, die sich wirklich unterscheiden

Es ist verlockend, eine App als Website mit einem schlechteren Browser zu behandeln. Vier Unterschiede zerbrechen diese Annahme, und jedes Werkzeug, das beide misst, braucht für jeden eine Antwort.

Es gibt keine URL. Eine Website hat eine Seitenadresse, die zugleich Name, Hierarchie und Gruppierungsmittel ist. Eine App hat Bildschirme, deren Namen Sie wählen und ändern können. Nichts erzwingt Einheitlichkeit, Checkout, checkout und CheckoutViewController landen also als drei Bildschirme im selben Bericht.

Es gibt kein Laden einer Seite. Im Web ist eine Navigation ein offensichtliches, beobachtbares Ereignis, das der Browser ankündigt. In einer App ist der Wechsel zwischen Bildschirmen ein Funktionsaufruf. Wenn nichts ihn erfasst, wird nichts aufgezeichnet, und es wird kein Fehler gemeldet.

Das Netz ist nicht verlässlich. Ein Browser-Tab ist meist online. Eine App regelmäßig nicht: ein Tunnel, ein Flugzeug, ein Funkloch. Ereignisse müssen auf dem Gerät eingereiht und später gesendet werden, was heißt, dass ein Werkzeug, das die Ankunftsreihenfolge für die Zeitreihenfolge hält, sie falsch ordnet, und eines, das nicht ahnt, dass ein Ereignis eingereiht war, es falsch stempelt.

Sitzungen enden anders. Eine Web-Sitzung läuft nach einer Zeit ohne Aktivität ab, herkömmlich nach dreißig Minuten. Eine App wird in den Hintergrund geschoben und kann dort tagelang sitzen, bevor sie mit noch lebendem Prozess in den Vordergrund zurückkehrt. Eine naive Sitzungsregel meldet eine Sitzung, die vier Tage dauerte.

Was „ein Ort" heißen sollte, und was es meist heißt

Die meisten Werkzeuge, die mit beidem werben, tun eines von zwei Dingen, und der Unterschied zählt mehr, als das Marketing nahelegt.

Das erste ist ein gemeinsames Dashboard über zwei völlig getrennten Datenbeständen. Sie bekommen eine Anmeldung. Sie bekommen keine eine Zahl, denn die beiden Seiten zählen verschiedene Dinge und nichts bringt sie in Einklang.

Das zweite ist ein Datenbestand mit einer Plattform-Spalte, damit ein Bericht gefiltert oder aufgeteilt werden kann. Das ist es, was Menschen meist zu kaufen glauben.

Es gibt eine dritte Anordnung, und es lohnt, sie deutlich zu sagen, denn sie ist die, die die Streitereien verursacht: Eine App und eine Website sind wirklich verschiedene Dinge, und sie in eine Einheit zu zwängen erzeugt Berichte, in denen keines von beiden stimmt. Ein Bildschirmaufruf ist kein Seitenaufruf. Eine App hat Versionen, eine Website nicht. Eine App stürzt ab; eine Website liefert eine 500.

Die brauchbare Anordnung ist, dass sie getrennte Einheiten mit eigenen Kennungen sind, vom selben Produkt gemessen, in derselben Oberfläche berichtet, aus demselben Konto bepreist. Sie können jedes ohne das andere ansehen, ohne dass die Form des anderen hineinsickert, und Sie können beide ansehen.

Fragen, die einem Anbieter zu stellen lohnen

  • Wie verhält sich das SDK offline? Genau: Reiht es ein, wie viele Ereignisse, was geschieht, wenn die Warteschlange voll ist, und bewahrt es den ursprünglichen Zeitstempel statt der Sendezeit?
  • Was geschieht mit einem fehlerhaften Ereignis? Ein SDK, das ein dauerhaft abgelehntes Ereignis für immer wiederholt, ist für Ihre Nutzer ein Batterie- und Datentarifproblem. Das richtige Verhalten ist, es zu verwerfen und das Verwerfen zu zählen.
  • Ist das Übertragungsformat versioniert? Apps aktualisieren nicht an einem Tag. Ein Teil Ihrer Nutzer wird auf einem Build von vor einem Jahr sein, und der Server muss weiter annehmen, was dieser Build sendet.
  • Wie wird ein Bildschirmname bestimmt? Wenn die Antwort „was immer Sie übergeben" lautet, fragen Sie, was das Werkzeug tut, um ihn einheitlich zu halten.
  • Wie lautet die Sitzungsregel nach einem Hintergrundwechsel? Eine bestimmte Zahl, nicht „wir kümmern uns darum".

Die dritte Frage erwischt mehr echte Probleme als der Rest zusammen, und sie ist die, die niemand stellt. Ein Web-Tracker lässt sich durch das Bearbeiten einer Seite ändern und ist noch am selben Nachmittag live. Ein App-SDK geht mit der App raus, wird über Wochen oder Monate angenommen und erreicht nie alle. Das Format zu brechen, das Ihre alten Builds senden, ist kein Fehler, den Sie schnell flicken können; es ist eine Flotte von Installationen, die aufhören zu melden.

Wo Skomi steht

Skomi behandelt eine gemessene App als eigene Einheit mit eigenem Schlüsselraum, neben Websites statt in ihnen. Die Berichte leben im selben Konto und werden gleich navigiert, aber eine App wird nie als Website beschrieben, und ihre Bildschirme heißen nie Seiten.

Es gibt SDKs für die gängigen Plattformen, und das Übertragungsformat, das sie sprechen, ist versioniert und eingefroren, genau deshalb, weil ein alter Build nicht aus der Ferne repariert werden kann. Die App-Analytics-Seite behandelt, was gemessen wird und welche Plattformen unterstützt sind.

Credits werden über alles im Konto geteilt (Websites und Apps gleichermaßen), eine App hinzuzufügen ist also kein zweites Abonnement. Die Preisseite hat die Rechnung.

Die beiden Hälften behalten ihr eigenes Vokabular, wo sie sich unterscheiden (eine Website hat Seitenaufrufe, eine App hat Bildschirmaufrufe), und teilen sich das Sitzungsfenster, das sie vergleichbar macht.