Amazon Datenschutzrichtlinie für Verkäufer und Apps: welche Käuferdaten eine Drittanbieter-App wirklich sieht

Zwei Dokumente, die für jede App auf Ihrem Konto gelten

Eine Klarstellung vorweg: Wenn Sie als Käufer wissen wollen, was Amazon mit Ihren eigenen Daten macht, ist die Amazon.de Datenschutzerklärung das richtige Dokument. Dieser Artikel richtet sich an Verkäufer, die Apps mit ihrem Verkäuferkonto verbinden, und er ist unsere Lesart der Regeln als Entwickler, keine Rechtsberatung.

Jeder Entwickler, der Amazons Selling Partner API nutzt, akzeptiert zwei Richtlinien. Die Data Protection Policy (DPP) regelt Sicherheit und Aufbewahrung, die Acceptable Use Policy (AUP) das Verhalten: was ein Entwickler anfordern darf und was er mit dem Erhaltenen tun darf. Beide sind öffentlich und beide bestimmen die Obergrenze für jede App, die Zugriff auf Ihr Konto möchte.

Die DPP hat zwei Ebenen. Abschnitt 1 gilt für "all systems that store, process, or otherwise handle data vended and retrieved from the Amazon Services API" (alle Systeme, die Daten aus der API verarbeiten), also für jede App, selbst für eine, die nur Ihren Tagesumsatz liest. Abschnitt 2 kommt erst dazu, wenn eine App PII berührt. Genau das ist der Kern: Eine App, die nie Käuferdaten erhält, bleibt auf der leichteren Ebene, und an den angeforderten Rollen erkennen Sie, welche Ebene gilt.

Aus der AUP zählen für Sie zwei Sätze. "Do not request access to or retrieve Information that is not necessary for your Application's functionality." (Fordern Sie keine Daten an, die Ihre Anwendung nicht braucht.) Und: "Do not request or share Amazon Portal usernames or passwords from Authorized Users." (Fragen Sie nicht nach Zugangsdaten der Nutzer.) Eine App, die Ihr Seller-Central-Passwort will oder eine Rolle nicht erklären kann, verstößt gegen die Regeln, bevor sie ein Byte gespeichert hat.

Für Verkäufer in Deutschland und Österreich liegt die DSGVO unter alldem, mit Datenminimierung und Zweckbindung im Kern. Was Auftragsverarbeitung für Ihr eigenes Datenschutzkonzept bedeutet, klären Sie mit Ihrem Berater; dieser Artikel bleibt bei Amazons Regeln.

Was als personenbezogene Daten gilt, Postleitzahl inklusive

Die DPP definiert PII als "information that can be used on its own or with other information to identify, contact, identify in context, or locate an Amazon Customer or Authorized User" (Daten, mit denen sich ein Amazon-Kunde identifizieren, kontaktieren oder lokalisieren lässt). Die Liste dahinter ist länger, als die meisten Verkäufer erwarten: "name, address, e-mail address, phone number, gift message content, survey responses, payment details, purchases, cookies, digital fingerprint (e.g., browser, user device), IP Address, geo-location, postal code, or Internet-connected device product identifier".

Zwei Punkte verdienen einen zweiten Blick. Erstens die Postleitzahl: allein wirkt sie harmlos, aber Amazon zählt sie zu PII, weil sie zusammen mit anderen Daten eine Person auffindbar macht. Zweitens, was nicht auf der Liste steht: eine Bestellzeile ohne jedes Käuferfeld. Dass jemand um 14:03 Uhr zwei Stück einer SKU auf amazon.de gekauft hat, identifiziert niemanden.

Die Postleitzahl-Falle in Bestellbenachrichtigungen

Dieses Detail haben wir erst beim Bauen einer App gefunden. Amazons Benachrichtigung ORDER_CHANGE, die Nachricht, die Entwickler für Bestellungen abonnieren, enthält in ihrer Bestellübersicht das Feld DestinationPostalCode. Wer sie so speichert, wie sie ankommt, hält damit PII und trägt die volle Last von Abschnitt 2: 30 Tage Aufbewahrung, Verschlüsselung im Ruhezustand, Schwachstellenscans, Penetrationstests. Wer das Feld vorher verwirft, bleibt in Abschnitt 1. Fragen Sie eine Alarm- oder Analyse-App, was sie mit der Postleitzahl macht. Wie schnell jemand die Frage versteht, sagt viel.

Restricted Data Tokens: das Tor vor den Käuferdaten

Amazon gibt einer App PII nicht schon deshalb, weil Sie sie autorisiert haben. Käuferdaten kommen aus der Orders API nur über sogenannte restricted operations, und die Tokens API sagt es unmissverständlich: "Restricted operations return customers' Personally Identifiable Information (PII). You need an RDT to call a restricted operation." (Für solche Aufrufe brauchen Sie einen RDT.) Ein Restricted Data Token muss die App für jeden dieser Aufrufe einzeln anfordern, und Amazon gibt ihn nur an Anwendungen aus, deren genehmigte Rollen die betreffenden Daten abdecken.

Im Datenmodell der Orders API tragen drei Objekte die Markierung restricted: ShippingAddress, BuyerInfo (Name, E-Mail-Adresse, Steuerdaten) und BuyerTaxInformation. Alles andere kommt ohne Token zurück. Damit arbeiten eine Bestellmeldung und ein Dashboard.

Zwei Nuancen. Die Bestellnummer steht nicht auf Amazons PII-Liste und kommt ohne Token zurück, lässt sich aber in Seller Central einem Käufer zuordnen; wir behandeln sie als pseudonyme Daten und speichern nur einen Hash mit Schlüssel. Und solange eine Bestellung ausstehend ist, liefert Amazon gar keine Preise, deshalb zeigt eine Meldungs-App bis zur Freigabe eine Schätzung.

Das Rollenmodell: was Sie beim Verbinden freigeben

Rollen sind in Amazons Worten "the mechanism by which the Selling Partner API (SP-API) determines whether a developer or application has access to an operation or resource" (der Mechanismus, der über den Zugriff entscheidet). Ein Entwickler beantragt sie bei der Registrierung, und Sie sehen sie beim Verbinden auf der Freigabeseite in Seller Central wieder. Was dort nicht steht, kann die App nicht aufrufen. Diese Seite gehen wir Schritt für Schritt durch in unserem Ratgeber App mit Amazon Seller Central verbinden.

Vier Rollen sind als restricted markiert: Direct-to-Consumer Shipping, Tax Invoicing, Tax Remittance und Professional Services. Amazons Rollenseite erklärt das Etikett: "Restricted means that the role requires sensitive information, which might include personally identifiable information (PII). For these roles, you must provide additional information about your data use and security controls." (Solche Rollen erfordern sensible Daten und zusätzliche Angaben zu Datennutzung und Sicherheitsmaßnahmen.) Nur sie schalten Restricted Data Tokens frei. Ein Etikettendruck-Tool braucht eine davon, ein Rechnungstool auch; eine Meldungs-App, ein Dashboard oder ein Repricer nicht.

Die Rolle für Bestellmeldungen heißt Inventory and Order Tracking, und ihre Beschreibung endet mit einem Satz, den man sich merken kann: "Operations that require this role do not use PII required to ship an order." (Sie nutzt keine PII, die zum Versand nötig wäre.) Sie liefert Bestellungen, Positionen und Verkaufskennzahlen und erlaubt das Abonnement von ORDER_CHANGE für FBA und FBM gleichermaßen. Fügt ein Entwickler später eine Rolle hinzu, verlangt Amazon eine neue Autorisierung; Sie sehen also eine neue Freigabeseite statt einer stillen Ausweitung.

Löschfristen und Prüfungen für Apps mit PII

Erhält eine App doch PII, ist die DPP klar. Ein Entwickler "will retain PII for no longer than 30 days after order delivery and only for the purpose of, and as long as is necessary to (i) fulfill orders, (ii) calculate and remit taxes, (iii) produce tax invoices and other legally required documents, and (iv) meet legal requirements". Also höchstens 30 Tage nach der Lieferung, mit steuerlichen und rechtlichen Pflichten als einzigem Grund für längere Aufbewahrung. Die AUP schließt die andere Tür: "Do not use Personally Identifiable Information about Customers for any purposes other than merchant-fulfilled shipping or to meet legal requirements."

Für Bestelldaten ohne Personenbezug gilt eine andere Uhr: Ein Entwickler darf sie nur so lange behalten, wie es für den freigegebenen Zweck nötig ist, und muss sie inklusive aller aktiven Kopien innerhalb von 30 Tagen nach Ihrem Widerruf endgültig löschen. Ein Tageszähler, den Sie weiter nutzen, ist so ein Zweck. Eine Kopie Ihrer Bestellungen nach dem Trennen ist es nicht.

Dazu kommen technische Pflichten: Verschlüsselung auf dem Transportweg mit "secure protocols such as TLS 1.2 or higher", Zugangsdaten "encrypted at rest, accessible only to authorized personnel, and rotated at least once every twelve (12) months", Zugriff nur nach dem Need-to-know-Prinzip. Wer PII speichert, muss sie zusätzlich im Ruhezustand verschlüsseln, "vulnerability scanning conducted at least every 30 days" durchführen und "perform penetration testing at least every 365 days". Obendrein darf Amazon prüfen und eine schriftliche Bestätigung der Einhaltung verlangen. Nichts davon sehen Sie als Verkäufer, und genau deshalb zählen die Rollen auf der Freigabeseite: Sie zeigen, welche dieser Pflichten der Entwickler übernommen hat und ob die App sie überhaupt brauchte.

Warum eine App für Bestellmeldungen davon nichts braucht

Überlegen Sie, was ein Cha-ching auf dem Smartphone wirklich braucht. Dass eine Bestellung existiert, damit die App sie einmal zählt. Wann sie aufgegeben wurde, damit die Meldung ihre Laufzeit zeigen kann. Auf welchem Marktplatz und ungefähr für wie viel. Vielleicht SKU oder Titel, damit Sie wissen, was sich verkauft hat. Jedes dieser Felder kommt über Inventory and Order Tracking ohne Restricted Data Token, und keines verrät, wer gekauft hat.

Der Name Ihres Käufers macht den Ton nicht schöner, seine Adresse die Meldung nicht schneller. Fürs Tempo zählt, wie eine App nach neuen Bestellungen sucht, und das haben wir gemessen: wie schnell eine Amazon Bestellbenachrichtigung sein kann. Eine App dieser Kategorie, die trotzdem Käuferdaten anfordert, hat die Richtlinie entweder missverstanden oder will die Daten für etwas anderes. Beides ist kein gutes Zeichen. Dasselbe gilt für die meisten Dashboards und selbst für die offizielle Seller App, deren Meldeverhalten wir in Benachrichtigungen der Amazon Seller App beschreiben.

So prüfen Sie, was eine App anfordert

Sie müssen keinen Quellcode lesen, um eine App einzuschätzen. Vier Prüfungen decken das meiste ab.

1. Lesen Sie die Freigabeseite, bevor Sie bestätigen. Sie listet jede angeforderte Rolle auf, und die Namen der eingeschränkten Rollen sind eindeutig: Direct-to-Consumer Shipping, Tax Invoicing, Tax Remittance, Professional Services.
2. Ordnen Sie jeder Rolle eine Funktion zu, die Sie nutzen wollen. Etikettendruck rechtfertigt Direct-to-Consumer Shipping, Rechnungsstellung rechtfertigt Tax Invoicing. Meldungen, Auswertungen, Repricing und Bestandsplanung rechtfertigen keine eingeschränkte Rolle.
3. Öffnen Sie die Datenschutzerklärung des Entwicklers und suchen Sie drei Antworten: Welche Felder werden gespeichert, wo stehen die Server, wie lange bleiben Daten nach dem Trennen? Die letzte Antwort darf laut DPP höchstens 30 Tage lauten.
4. Stellen Sie eine Frage per E-Mail: "Speichern Sie Käuferdaten, und was machen Sie mit der Postleitzahl aus der Bestellbenachrichtigung?" Wer die Richtlinie gelesen hat, antwortet in zwei Zeilen.

Fordert eine App mehr an, als ihre Funktionen brauchen, bestätigen Sie nicht; die AUP verbietet das ausdrücklich, Sie sind also nicht kleinlich. Haben Sie schon verbunden, widerrufen Sie: in Seller Central unter Apps und Services, Ihre Apps verwalten, die App suchen, Autorisierung deaktivieren, mit OK bestätigen. Amazons Dokumentation weist darauf hin, dass die App danach deaktiviert ist, aber auf der Seite sichtbar bleibt; sie dort noch zu sehen, ist normal. Ab diesem Moment hat der Entwickler 30 Tage, um Ihre Daten zu löschen. Und wenn Sie die App verbunden haben, um Ihre Verkäufe zu hören: Unsere Übersicht wie Sie bei einem Amazon-Verkauf benachrichtigt werden zeigt, welche Wege ganz ohne Käuferdaten auskommen.