Show Menu
THEMEN×

Fehlerbehebung bei Daten-Feeds

Dieser Abschnitt enthält Informationen zu allgemeinen Problemen.

Fehler beim Speichern des Feeds

Datenfeed-Dateinamen umfassen die Report Suite-ID und das Datum. Zwei Feeds, die für dieselbe RSID und denselben Termin bzw. dieselben Termine konfiguriert sind, haben denselben Dateinamen. Wenn diese Feeds in dasselbe Verzeichnis gesendet werden, überschreibt eine Datei die andere. Um das Überschreiben einer Datei zu verhindern, können Sie keinen Feed erstellen, der einen vorhandenen Feed im selben Verzeichnis überschreiben könnte.
Wenn Sie versuchen, einen Feed mit dem Dateinamen eines anderen Feeds zu erstellen, führt dies zu der folgenden Meldung:
Wenn dieser Fehler vorliegt, ziehen Sie die folgenden Fehlerumgehungen in Erwägung:
  • Bereitstellungspfad ändern
  • Termine ändern, falls möglich
  • Report Suite ändern, falls möglich

BucketOwnerFullControl-Einstellungen für Amazon S3-Datenfeeds

Bei einer üblichen Verwendung von Amazon S3 erstellt der Kontoinhaber eines Amazon Web Services (AWS)-Kontos zunächst einen Bucket. Dann erstellt er einen Benutzer, der dazu berechtigt ist, Objekte in diesem Bucket zu erstellen. Schließlich stellt der Kontoinhaber die Anmeldeinformationen für diesen Benutzer zur Verfügung. In diesem Fall gehören die Objekte eines Benutzers zum selben Konto und der Kontoinhaber hat implizit die vollständige Kontrolle über das Objekt (lesen, löschen, usw.). Dies entspricht der Funktionsweise der FTP-Bereitstellung.
Mit AWS kann ein Benutzer aber auch Objekte in einem Bucket erstellen, die einem völlig anderen Benutzerkonto zugeordnet sind. Beispiel: Zwei AWS-Benutzer, Benutzer A und Benutzer B, verfügen über kein gemeinsames AWS-Konto, möchten aber in einem anderen Bucket Objekte erstellen. Erstellt Benutzer A einen Bucket, beispielsweise Bucket A, so kann Benutzer A eine Bucket-Richtlinie festlegen, die Benutzer B explizit erlaubt, in Bucket A Objekte zu erstellen, auch wenn der Bucket nicht Benutzer B gehört. Dies kann vorteilhaft sein, da es nicht notwendig ist, dass Benutzer A und Benutzer B Anmeldeinformationen austauschen. Stattdessen stellt Benutzer B Benutzer A die Nummer seines Benutzerkontos zur Verfügung und Benutzer A erstellt eine Bucket-Richtlinie, die im Wesentlichen aussagt, dass „Benutzer B Objekte in Bucket A erstellen darf“.
BucketOwnerFullControl beinhaltet kontenübergreifende Berechtigungen zum Erstellen von Objekten in anderen Buckets. Lädt Benutzer B ein Objekt in den Bucket von Benutzer A, „gehört“ das Objekt immer noch Benutzer B und Benutzer A hat standardmäßig keine Berechtigungen an dem Objekt, auch wenn der Bucket Benutzer A gehört – Objekte erben keine Berechtigungen des übergeordneten Buckets. Benutzer B muss Benutzer A explizit Berechtigungen einräumen, da Benutzer B immer noch der Eigentümer des Objekts ist. Für dieses kontenübergreifende Hochladen bietet AWS eine BucketOwnerFullControl-ACL, die vom Eigentümer des Behälters (Benutzer A) verwendet werden kann und vollständige Berechtigungen an dem Objekt (lesen, schreiben, löschen, etc.) beinhaltet, auch wenn das Objekt Benutzer B „gehört“.

Übertragungsfehler

Im Fall eines FTP-Übertragungsfehlers (Anmeldung verweigert, Verbindung getrennt, Kontingent überschritten usw.) versucht Adobe automatisch, eine Verbindung herzustellen und sendet die Daten bis zu drei Mal separat. Sollten die Fehler weiterhin bestehen, wird der Feed als fehlgeschlagen markiert und es wird eine E-Mail-Benachrichtigung gesendet.
Im Fall eines Übertragungsfehlers können Sie einen Auftrag erneut ausführen, bis der Vorgang erfolgreich ausgeführt wird.

Optionen zum erneuten Senden

Nachdem Sie das Bereitstellungsproblem überprüft/korrigiert haben, führen Sie den Auftrag erneut aus, um die Dateien abzurufen.

Auswirkungen der Sommerzeit auf stündliche Datenfeeds

Für einige Zeitzonen ändert sich zweimal jährlich die Uhrzeit aufgrund der Sommerzeitdefinition. Die Datenfeeds berücksichtigen die Zeitzone, für die die Report Suite konfiguriert ist. Wenn in der für die Report Suite gewählten Zeitzone keine Sommerzeit berücksichtigt wird, erfolgt die Dateibereitstellung ganz normal wie an den anderen Tagen des Jahres. Wenn in der für die Report Suite gewählten Zeitzone jedoch die Sommerzeit berücksichtigt wird, ändert sich die Dateibereitstellung für die Stunde, in der die Zeitumstellung erfolgt (normalerweise 2:00 Uhr morgens).
Bei STD-> DST-Zeitübergängen ("Spring Forward") erhält der Kunde nur 23 Dateien. Die Stunde, die bei der Zeitumstellung übersprungen wird, entfällt. Wenn der Übergang z. B. um 2 Uhr erfolgt, erhalten sie eine Datei für 1 Uhr und eine Datei für 3 Uhr. Es gibt keine Datei für 2:00 Uhr, da 2:00 Uhr Normalzeit der Sommerzeit-Uhrzeit 3:00 Uhr entspricht.
Bei DST-> STD-Übergängen ("Fall Back") erhält der Kunde 24 Dateien. Die Stunde des Übergangs umfasst jedoch Daten von 2 Stunden. Beispiel: Wenn die Umstellung 2:00 Uhr erfolgt, erhalten die Kunden die Datei für 1:00 Uhr verspätet, diese umfasst jedoch Daten für insgesamt zwei Stunden. Nämlich Daten von 1:00 Uhr Sommerzeit bis 2:00 Uhr Normalzeit (was 3:00 Uhr nach Sommerzeit entspricht). Die nächste Datei beginnt ab 2:00 Uhr Normalzeit.

Keine Daten für Zeitraum

Sie können einen Datenfeed optional so konfigurieren, dass eine Manifestdatei bereitgestellt wird, wenn für einen bestimmten Zeitraum keine Daten erfasst werden. Wenn Sie diese Option aktivieren, erhalten Sie eine Manifestdatei, die folgendem Schema entspricht:
Datafeed-Manifest-Version: 1.0
 Lookup-Files: 0
 Data-Files: 0
 Total-Records: 0

Keine Domäneninfo für Domänenberichterstellung

Einige Mobilfunknetzbetreiber (wie T-Mobile und O1) bieten keine Domänen mehr für Reverse-DNS-Lookups an. Daher sind die Daten nicht für die Domänenberichterstellung verfügbar.

Übersicht zu Datenverarbeitung

Bevor Sie stündliche oder tägliche Daten verarbeiten können, warten die Datenfeeds, bis alle Treffer, die innerhalb des Zeitrahmens (Tag oder Stunde) in die Datenerfassung eingehen, aus dem Data Warehouse geschrieben werden. Anschließend erfassen die Datenfeeds die Daten mit Zeitstempeln, die in diesen Zeitrahmen fallen, komprimieren die Daten und senden sie per FTP. Bei stündlichen Feeds werden die Daten normalerweise innerhalb von 15 bis 30 Minuten nach Ablauf der entsprechenden Stunde aus dem Data Warehouse geschrieben, es gibt jedoch keinen festgelegten Zeitraum. Wenn es keine Daten mit Zeitstempeln gibt, die in diesen Zeitrahmen passen, erfolgt der Prozess im nächsten Zeitrahmen erneut. Der aktuelle Datenfeedprozess nutzt das Feld date_time , um zu ermitteln, welche Treffer zur entsprechenden Stunde gehören. Dieses Feld basiert auf der Zeitzone der Report Suite.