مشكلة مفاتيح API التي لا تنتهي صلاحيتها أبدًا
المفتاح الذي صدر قبل سنوات، ولم يُبدَّل قط، ولا يزال صالحًا حتى اليوم ليس ميزة مريحة. إنه عبء لم ينظر فيه أحد فعلًا منذ سنوات.
ما الذي تخطئ فيه الفوترة حسب المنتج بشأن طريقة استخدام واجهات API
افتح سجل الطلبات لأي تطبيق تقريبًا يستخدم بيانات الموقع ولن تجد نوعًا واحدًا من الاستعلامات يعمل بمعزل عن غيره. نموذج تسجيل يرمّز عنوانًا جغرافيًا، ويفحص IP لمطابقة تقريبية للشبكة، ويختم السجل بمنطقة زمنية، كل ذلك في بضع مئات من الأجزاء من الثانية نفسها. هذه ليست ثلاث حالات استخدام منفصلة يصادف أنها تتقاسم مزود API واحدًا. إنها سير عمل واحد يلامس ثلاثة أنواع من البيانات.
تتظاهر الفوترة لكل منتج بعكس ذلك. فهي تسعّر الترميز الجغرافي في فئة، واستعلامات IP في فئة أخرى، وبيانات المنطقة الزمنية أو الارتفاع كإضافات اختيارية لكل منها رسومها المنفصلة، كأن الشركة التي تحتاج إلى أحدها يُستبعد أن تحتاج إلى الأخرى. وعمليًا، العكس هو الصحيح: الحاجة إلى أحدها علامة عادةً على أنك تحتاج إلى واحد آخر على الأقل. صفحة الدفع في متجر إلكتروني ترمّز عنوان الشحن جغرافيًا تريد في الغالب أيضًا معرفة المنطقة الزمنية التي تُجدول فيها نافذة التوصيل. وفحص الاحتيال الذي ينظر في عنوان IP يريد عادةً مقارنته بعنوان مسجل في الملف.
سعّرنا My Geocode كمنتج واحد بسعر واحد. كل نقطة نهاية، من الترميز الجغرافي والاستعلام عن IP والمنطقة الزمنية والارتفاع والرمز البريدي، وكل مضيف توافق، يكلّف الشيء نفسه تمامًا لكل طلب. لا توجد قائمة أسعار منفصلة للتوفيق بينها، ولا فئة تضيف بيانات المنطقة الزمنية فقط بعد أن تكون قد دفعت بالفعل مقابل فئة الترميز الجغرافي. الطلب طلب، أيًا كانت نقطة النهاية التي يصل إليها.
ليس هذا مجرد راحة للعميل. إنه يعكس الطريقة التي يجري بها العمل الأساسي فعلًا. فالاستعلام من نقطة نهاية لا يحمل تكلفة خدمة مختلفة جذريًا عن استعلام من نقطة أخرى على النطاق الذي تعمل به معظم التطبيقات. وتقسيمها إلى منتجات منفصلة بنقاط سعرية منفصلة لا يتبع فرقًا حقيقيًا في تكلفة الإجابة عن الطلب. إنه يتبع عدد البنود المنفصلة التي يستطيع المزود وضعها في الفاتورة.
تجعل الفوترة لكل منتج أيضًا التفكير في استخدامك أصعب. إذا كان الترميز الجغرافي يُفوتر بطريقة واستعلامات IP بطريقة أخرى، فإن تقدير فاتورة الشهر المقبل يعني تتبع عدّادين مقابل هيكلي أسعار، والأمل في ألا يتغير مزيج الاستدعاءات بطريقة تغيّر الإجمالي بشكل غير متوقع. السعر الموحد الثابت يختزل هذا التقدير في رقم واحد: إجمالي الطلبات مضروبًا في سعر واحد. ويستطيع أي شخص يضع ميزانية لتكامله أن يجري هذه العملية الحسابية على ظهر مغلف.
هناك افتراض أعمق مدفون في التسعير لكل منتج نعتقد أنه خاطئ ببساطة: أن الأنواع المختلفة من بيانات الموقع تخدم عملاء مختلفين. في تجربتنا، هي تخدم العميل نفسه، في نقاط مختلفة من الطلب نفسه. منصة لوجستية، ومسار تسجيل، ونظام لمكافحة الاحتيال، كلها تربط بيانات الترميز الجغرافي وIP والمنطقة الزمنية معًا في قرار واحد. والتسعير الذي يتظاهر بأنها أسواق منفصلة يجبر العملاء إما على دفع مبالغ زائدة مقابل حزمة يستخدمونها بشكل متفاوت، وإما على التنقل بين عدة موردين لتجنب ذلك. سعر واحد وقائمة واحدة لنقاط النهاية هو الإجابة الأبسط والأصدق.