Berichtszeitverarbeitung

Berichtszeitverarbeitung ist eine Virtual Report Suite-Einstellung, die eine nicht destruktive, rückwirkende Verarbeitung von Daten in Analysis Workspace ermöglicht.

Berichtszeitverarbeitung betrifft nur die Daten in der Virtual Report Suite und hat keinen Einfluss auf Daten oder die Datenerfassung in der zugrunde liegenden Report Suite. Der Unterschied zwischen Berichtszeitverarbeitung und der herkömmlichen Analytics-Verarbeitung lässt sich am besten anhand des folgenden Diagramms veranschaulichen:

Herkömmliche Verarbeitungs-Pipeline

Während der Analytics-Datenverarbeitung fließen Daten durch die Datenerfassungs-Pipeline und in einen Vorverarbeitungsschritt, der Daten für das Reporting vorbereitet. In diesem Vorverarbeitungsschritt werden die Besuchsgültigkeitslogik und die eVar-Persistenzlogik (unter anderem) auf die Daten zum Zeitpunkt ihrer Erfassung angewendet. Der Hauptnachteil dieses Vorverarbeitungsmodells besteht darin, dass vor der Datenerfassung jede Konfiguration vorgenommen werden muss. Das bedeutet, dass Änderungen an den Vorverarbeitungseinstellungen nur für neue Daten ab diesem Zeitpunkt gelten. Dies ist problematisch, wenn die Daten nicht in der richtigen Reihenfolge eingehen oder die Einstellungen falsch konfiguriert waren.

Berichtszeitverarbeitung ist eine völlig andere Methode zur Verarbeitung von Analytics-Daten für die Berichterstellung. Anstatt vor dem Erfassen von Daten die Verarbeitungslogik vorab zu bestimmen, ignoriert Analytics die während des Vorverarbeitungsschritts festgelegten Daten und wendet diese Logik bei jeder Berichtsausführung an:

Pipeline zur Berichtszeitverarbeitung

Diese Verarbeitungsarchitektur ermöglicht deutlich flexiblere Berichtsoptionen. Sie können beispielsweise die Zeitüberschreitungsdauer für Besuche zerstörungsfrei auf eine beliebige Zeitdauer ändern. Diese Änderungen werden in Ihren eVar-Persistenz- und Segment-Containern für den gesamten Berichtszeitraum übernommen. Zudem können Sie eine beliebige Anzahl von Virtual Report Suites mit jeweils unterschiedlichen Optionen zu Berichtszeitverarbeitung generieren, die auf derselben zugrunde liegenden Report Suite basieren, ohne Daten in der zugrunde liegenden Report Suite zu ändern.

Mit Berichtszeitverarbeitung kann in Analytics verhindert werden, dass durch Hintergrundtreffer neue Besuche gestartet werden, und der Adobe Experience Platform Mobile SDK kann bei jedem Auslösen eines Startereignisses einer Mobile App einen neuen Besuch starten.

Konfigurationsoptionen

Die folgenden Konfigurationsoptionen sind derzeit für Virtual Report Suites mit aktivierter Berichtszeitverarbeitung verfügbar:

  • Timeout für Besuch: Mit dieser Einstellung wird die Dauer der Inaktivität eines Unique Visitor definiert, bevor automatisch ein neuer Besuch gestartet wird. Die Standardeinstellung lautet 30 Minuten. Wenn Sie beispielsweise das Besuchs-Timeout auf 15 Minuten festlegen, wird für jede erfasste Sequenz von Treffern eine neue Besuchergruppe erstellt, getrennt durch 15 Minuten Inaktivität. Diese Einstellung wirkt sich nicht nur auf die Anzahl Ihrer Besuche aus, sondern auch darauf, wie Besuchssegment-Container ausgewertet werden und wie die Logik des Besuchsablaufs für alle eVars funktioniert, die beim Besuch ablaufen. Wenn Sie die maximale Wartezeit für Besuche verringern, wird sich wahrscheinlich die Gesamtzahl der Besuche in Ihren Berichten erhöhen, während eine Erhöhung der maximalen Wartezeit für Besuche wahrscheinlich die Gesamtzahl der Besuche in Ihren Berichten verringert.
  • Besuchseinstellungen für Mobile Apps: Für Report Suites mit Daten, die von Mobile Apps über die Adobe Mobile SDKs generiert wurden, sind zusätzliche Besuchseinstellungen verfügbar. Diese Einstellungen sind zerstörungsfrei und betreffen nur Treffer, die über die Mobile SDKs erfasst wurden. Diese Einstellungen haben keine Auswirkungen auf Daten, die außerhalb der Mobile SDK erfasst werden.
  • Starten neuer Besuche durch Hintergrundtreffer verhindern: Hintergrundtreffer werden von den Mobile SDKs erfasst, wenn sich die Mobile App in einem Hintergrundzustand befindet.
  • Bei jedem Anwendungsstart einen neuen Besuch starten: Zusätzlich zum Timeout für Besuche können Sie immer dann den Beginn eines Besuchs erzwingen, wenn von den Mobile SDKs ein Startereignis einer App aufgezeichnet wurde. Die Inaktivitätsdauer ist dabei unerheblich. Diese Einstellung hat einen Einfluss auf die Besuchsmetrik und den Besuchssegment-Container sowie die Besuchsgültigkeitslogik für eVars.
  • Neuen Besuch mit Ereignis starten: Eine neue Sitzung beginnt dann, wenn ein Ereignis ausgelöst wird – unabhängig davon, ob bei einer Sitzung eine Zeitüberschreitung aufgetreten ist oder nicht. Die neu erstellte Sitzung enthält das Ereignis, mit dem sie gestartet wurde. Darüber hinaus können Sie mehrere Ereignisse verwenden, um eine Sitzung zu starten. Eine neue Sitzung wird ausgelöst, wenn eines dieser Ereignisse in den Daten beobachtet wird. Diese Einstellung wirkt sich auf die Anzahl der Besuche, den Besuchssegmentierungs-Container und die Logik des Besuchsablaufs für eVars aus.
recommendation-more-help

Siehe VideoCheckedOut Starten eines neuen Besuchs mit einem Ereignis für ein Demovideo.

Einschränkungen bei der Berichtszeitverarbeitung

Die Berichtszeitverarbeitung unterstützt nicht alle Metriken und Dimensionen, die in der herkömmlichen Analytics-Berichterstellung verfügbar sind. Auf Virtual Report Suites mit Berichtszeitverarbeitung kann nur über Analysis Workspace zugegriffen werden, nicht aber über Data Warehouse, Report Builder, Daten-Feeds oder der Reporting-API.

Zudem werden bei „Berichtszeitverarbeitung“ nur Daten verarbeitet, die aus dem Datumsbereich der Berichterstellung stammen (nachfolgend als „Datumsfenster“ bezeichnet). Das bedeutet, dass eVar-Werte, die für eine Besucherin oder einen Besucher vor dem Berichtsdatumsbereich auf „läuft nie ab“ festgelegt wurden, nicht in den Berichtsfenstern beibehalten werden und nicht in Berichten angezeigt werden. Dies bedeutet auch, dass die Messungen der Kundentreue ausschließlich auf den im Datumsbereich des Berichts vorhandenen Daten basieren und nicht auf dem gesamten Verlauf vor dem Datumsbereich des Berichts.

Die folgenden Dimensionen und Metriken werden bei der Berichtszeitverarbeitung nicht unterstützt:

Betroffene Dimensionen und Metriken

Nachstehend finden Sie eine Liste mit Dimensionen und Metriken, die je nach den ausgewählten Einstellungen für „Berichtszeitverarbeitung“ betroffen sind:

  • Wenn „Starten neuer Besuche durch Hintergrundtreffer verhindern“ aktiviert ist, treten die folgenden Änderungen ein. Weitere Informationen finden Sie unter kontextbezogene Sitzungserstellung.

    • Bounces/Bounce-Rate: Hintergrundtreffer, auf die kein Vordergrundtreffer folgt, werden nicht als Bounce-Treffer betrachtet und tragen nicht zur Bounce-Rate bei.
    • Zeit pro Besuch in Sekunden: Nur Besuche mit Treffern im Vordergrund tragen zu dieser Metrik bei.
    • Zeit pro Besuch: Nur Besuche, die Treffer im Vordergrund enthalten, tragen zu dieser Metrik bei.
    • Einstiegsmetrik/Ausstiegsmetrik: In dieser Dimension werden nur Ein- und Ausstiege aus Besuchen mit Vordergrundtreffern angezeigt.
    • Einstiegsdimension / Ausstiegsdimensionen: In dieser Dimension werden nur Ein- und Ausstiege aus Besuchen mit Vordergrundtreffern angezeigt.
    • Metrik „Unique Visitors“ „Unique Visitors“ umfasst keine Besucher, die im Datumsbereich der Berichterstellung nur Hintergrundtreffer hatten.
  • Besuche: Besuche spiegeln die konfigurierten Einstellungen der Virtual Report Suite wider, die sich von der zugrunde liegenden Report Suite unterscheiden können.

  • Serialisierte Ereignisse mit Ereignis-ID: Ereignisse, die die Ereignisserialisierung mit einer Ereignis-ID verwenden, werden nur für Ereignisse dedupliziert, die innerhalb des Datumsbereichs der Berichterstellung für einen Besucher auftreten. Diese Ereignisse werden aufgrund des Datumsfensters für die Berichtszeitverarbeitung nicht global für alle Daten oder Besucher dedupliziert.

  • Bestellungen / Umsatz / Bestellungen / Einheiten: Wenn die Kauf-ID verwendet wird, werden diese Metriken nur für doppelte Kauf-IDs dedupliziert, die innerhalb des Berichtsdatumsbereichs für einen Besucher auftreten, und nicht für alle Datumsangaben oder Besucher global aufgrund des Fensters Berichtszeitverarbeitung .

  • Nicht-Merchandising-eVars/reservierte eVars: Werte, die in einer eVar festgelegt wurden, bleiben nur erhalten, wenn der Wert aufgrund des Fensters Berichtszeitverarbeitung innerhalb des Berichtsdatumsbereichs festgelegt wurde. Zudem können zeitbasierte Abläufe eine Stunde zu früh oder zu spät ablaufen, wenn sich die Persistenz über eine Zeitumstellung erstreckt.

  • Merchandising-eVars/reservierte eVars: Siehe oben. Zudem wird bezüglich der Konversionssyntax „Beliebige Treffer“ verwendet, wenn die Bindung auf „Beliebiges Ereignis“ festgelegt ist.

  • Treffertyp: Diese Dimension gibt an, ob es sich bei einem Treffer um einen Vorder- oder Hintergrundtreffer handelt.

  • Dimensionen mit (Low-Traffic) oder „Eindeutige Werte überschritten“: Der Zeileneintrag (Low-Traffic) wird bei der Verwendung der Berichtszeitverarbeitung geringfügig anders bestimmt als bei der Berichterstellung für die zugrunde liegende Report Suite. Dimension-Zeileneinträge, die nicht Teil von Low-Traffic sind, stellen garantiert nicht 100 % der Daten für diesen Zeileneintrag dar. Diese Unterschiede können umso ausgeprägter sein, je höher die Anzahl der eindeutigen Werte in einer Dimension ist.

46b8682c-fda6-4669-9355-1a44923e549e