Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Was die Abrechnung pro Produkt an der Art, wie APIs genutzt werden, falsch versteht
Öffnen Sie das Anfrageprotokoll fast jeder Anwendung, die Standortdaten nutzt, und Sie werden keine Art von Abfrage finden, die isoliert läuft. Ein Registrierungsformular geokodiert eine Adresse, prüft die IP auf eine grobe Netzwerkübereinstimmung und versieht den Datensatz mit einer Zeitzone, alles innerhalb derselben paar hundert Millisekunden. Das sind keine drei getrennten Anwendungsfälle, die zufällig denselben API-Anbieter nutzen. Es ist ein Arbeitsablauf, der drei Arten von Daten berührt.
Die Abrechnung pro Produkt tut so, als sei es anders. Sie bepreist Geokodierung in einer Stufe, IP-Abfragen in einer anderen und Zeitzonen- oder Höhendaten als optionale Zusätze mit eigenen Gebühren, als sei ein Unternehmen, das eines davon braucht, kaum auf die anderen angewiesen. In der Praxis ist das Gegenteil der Fall: Wer eines davon braucht, braucht meist mindestens ein weiteres. Ein E-Commerce-Checkout, der eine Lieferadresse geokodiert, will mit ziemlicher Sicherheit auch wissen, in welcher Zeitzone ein Lieferfenster geplant werden soll. Eine Betrugsprüfung, die eine IP-Adresse untersucht, will sie meist mit einer hinterlegten Adresse abgleichen.
Wir haben My Geocode als ein Produkt mit einem Tarif bepreist. Jeder Endpunkt, Geokodierung, IP-Abfrage, Zeitzone, Höhe, Postleitzahl, und jeder Kompatibilitäts-Host kostet pro Anfrage genau dasselbe. Es gibt keine separate Preisliste abzugleichen und keine Stufe, die Zeitzonendaten erst hinzufügt, nachdem Sie bereits für eine Geokodierungsstufe bezahlt haben. Eine Anfrage ist eine Anfrage, egal welchen Endpunkt sie aufruft.
Das ist nicht nur eine Erleichterung für den Kunden. Es spiegelt wider, wie die zugrunde liegende Arbeit tatsächlich abläuft. Eine Abfrage an einem Endpunkt verursacht in dem Umfang, in dem die meisten Anwendungen laufen, keine völlig anderen Bereitstellungskosten als eine Abfrage an einem anderen. Sie in getrennte Produkte mit getrennten Preispunkten aufzuteilen, bildet keinen echten Unterschied darin ab, was die Beantwortung der Anfrage kostet. Es bildet ab, wie viele separate Posten ein Anbieter auf eine Rechnung setzen kann.
Die Abrechnung pro Produkt erschwert es außerdem, die eigene Nutzung zu überblicken. Wenn Geokodierung auf eine Art und IP-Abfragen auf eine andere abgerechnet werden, bedeutet eine Schätzung der Rechnung für den nächsten Monat, zwei Zähler gegen zwei Tarifstrukturen zu verfolgen und zu hoffen, dass sich die Mischung der Aufrufe nicht so verschiebt, dass sich die Summe unvorhersehbar ändert. Ein pauschaler, einheitlicher Tarif reduziert diese Schätzung auf eine Zahl: Gesamtzahl der Anfragen mal ein Preis. Wer ein Budget für seine Integration aufstellt, kann das auf einem Bierdeckel ausrechnen.
In der Bepreisung pro Produkt steckt eine tiefere Annahme, die wir schlicht für falsch halten: dass verschiedene Arten von Standortdaten verschiedenen Kunden dienen. Unserer Erfahrung nach dienen sie demselben Kunden, an verschiedenen Stellen derselben Anfrage. Eine Logistikplattform, ein Registrierungsablauf und ein Betrugserkennungssystem verknüpfen alle Geokodierungs-, IP- und Zeitzonendaten zu einer Entscheidung. Eine Bepreisung, die so tut, als seien das getrennte Märkte, zwingt Kunden, entweder zu viel für ein Paket zu zahlen, das sie ungleichmäßig nutzen, oder mit mehreren Anbietern zu jonglieren, um das zu vermeiden. Ein Tarif und eine Liste von Endpunkten ist die einfachere und ehrlichere Antwort.