Tracking API тарифтеу үлгілері түсіндірілді: әрбір сұрау үшін төлемге қарсы әрбір жөнелтілім үшін төлем және нақты құныңызды қалай есептеу керек
Қоңырау бойынша есептелетін Tracking API бағасы төлем алынатын сұраулар үшін алынады; жөнелтілім бойынша баға тіркелген бақылау нөмірі сияқты анықталған бақылау бірлігі үшін алынады. Олардың ешқайсысы автоматты түрде арзанырақ емес. Нақты шығынды бағалау үшін екі модельді де бірдей жөнелтілім көлеміне, жаңарту талаптарына, бақылау ұзақтығына және есеп айырысу ережелеріне салыстырып, кейін платформа ақысын, артық пайдалануды және интеграция шығындарын қосыңыз.
Инженерлік, операциялық және сатып алу топтары үшін пайдалы салыстыру — қоңырау бойынша бағаны жөнелтілім бойынша бағамен жай ғана салыстыру емес. Мәселе — бизнесіңізге қажет жөнелтілім көрінуін қамтамасыз етудің жалпы құны. Сұрау жиілігі төмен болғанымен, жиі polling қолданылса, қымбатқа түсуі мүмкін, ал жөнелтілім бойынша төмен баға бақылау терезесі немесе қамтылған қызметтер жұмыс процесіңізге сәйкес келмесе, жаңылыстыруы ықтимал.
Әрбір баға моделі нақты нені өлшейді
Бірінші қадам — үш нәрсені ажырату: API сұрауы, жөнелтілімді тіркеу және бақылау жаңартуы. Бұлар әртүрлі оқиғалар, әрі келісімшарт олардың әрқайсысына әртүрлі есеп айырысу тәртібін белгілеуі мүмкін.
| Салыстыру тармағы | Қоңырау бойынша баға | Жөнелтілім бойынша баға |
|---|---|---|
| Есеп айырысу негізі | Төлем алынатын деп анықталған сұраулар немесе сұрау бірліктері | Төлем алынатын деп анықталған жөнелтілім бірліктері |
| Негізгі шығын факторы | Қосымша ақы алынатын сұрауларды қолданбаның қаншалықты жиі жіберетіні | Қосымша ақы алынатын бақылау бірліктерінің қаншасы ауқымға кіретіні немесе сонда қалатыны |
| Шешілуі тиіс есеп айырысу сұрағы | Қай endpoint-тер, жауаптар және пакет элементтері есепке алынады? | Бір жөнелтілім нені білдіреді және бақылау қанша уақыт қамтылады? |
| Ықтимал шығын тәуекелі | Қайталама polling, қайта жіберулер және қажетсіз іздеулер | Қайталанатын тіркеулер, бірнеше сәлемдеме және бақылау терезесінің шектеулері |
| Ең қолайлы шартты жағдай | Сұрау көлемі бақыланатын, сирек орындалатын іздеулер | Жаңартулар жөнелтілім ақысына кіретін үздіксіз мониторинг |
Қоңырау бойынша баға әр HTTP сұрауы бірдей тұрады дегенді білдірмейді
Коммерциялық ұсыныста төлем алынатын endpoint-тер мен олардың бірліктері көрсетілуі керек. Бақылау нөмірін тіркеу, сақталған нәтижелерді алу, жаңартуды сұрау және жазылымдарды басқару әртүрлі есептелуі мүмкін. Сәтсіз сұрау тегін немесе сәтті сұрау әрдайым ақылы болады деп ойламаңыз.
Пакеттеу де нақты анықталуы керек. 100 бақылау нөмірі бар бір сұрау бір сұрау, 100 бақылау бірлігі немесе келісімшартта көрсетілген басқа мөлшер ретінде есептелуі мүмкін. Метролинг ережелері оны қолдамайынша, желілік трафикті азайту есеп айырысу шығынын азайтпайды.
Жөнелтілім бойынша баға міндетті түрде тапсырыс бойынша баға емес
Электрондық коммерциядағы бір тапсырыс бірнеше сәлемдемеге бөлінуі мүмкін. Егер төлем алынатын бірлік бақылау нөмірі болса, бөлінген тапсырыс бірнеше бірлікті пайдалануы ықтимал. Қайтарымдар, ауыстырылатын жөнелтілімдер және тасымалдаушы ауысуы да нақты реттелуі керек.
Ақы белгілі бір кезеңге, белгіленген аяқталу оқиғасына дейін немесе басқа шектеу бойынша бақылауды сатып ала ма — соны сұраңыз. Бұған қоса, бұрын тіркелген жөнелтілімдер келесі есеп айырысу кезеңінде жаңа ақыға ұшырай ма, анықтаңыз. Бұл мәліметтер баға жоспарының атауынан маңыздырақ.
Шығынды тек тапсырыс санынан емес, жұмыс процесіңізден есептеңіз
Өкілдік операциялық кезеңді пайдаланып, жөнелтілім деңгейіндегі деректер негізінде болжам жасаңыз. Жаңа жөнелтілімдерді де, әлі де мониторингті қажет ететін ескі жөнелтілімдерді де қосыңыз. Деректеріңіз толық болмаса, нәтижені дәл коммерциялық ұсыныс ретінде көрсетпей, болжамдарды ашық көрсетіңіз.
- Бақыланатын сәлемдемелерді санаңыз. Checkout тапсырыстарынан емес, бірегей сәлемдеме бақылау бірліктерінен бастаңыз. Есеп айырысу тәртібі нақтыланғанша, жөнелтілетін сәлемдемелерді, қайтарымдарды және ауыстыруларды бөлек ұстаңыз.
- Мониторинг ұзақтығын өлшеңіз. Әр жөнелтілімге жаңартулар қанша уақыт қажет екенін, қажет болған жағдайда транзитке дейінгі және ерекше жағдай кезеңдерін қоса бағалаңыз.
- Қажетті жаңарту жиілігін анықтаңыз. Қолданбаңызға жаңа ақпарат қаншалықты жиі қажет екенін және бұл жиілік жөнелтілім мәртебесіне қарай өзгеретін-өзгермейтінін көрсетіңіз.
- API жұмыс процесін картаға түсіріңіз. Интеграцияңыз пайдаланатын тіркеулерді, нәтижелерді іздеуді, жаңарту сұрауларын, түзетулерді, қайта жіберулерді және басқа endpoint-терді тізімдеңіз.
- Есеп айырысу ережелерін қолданыңыз. Ұсынылған келісімшарт негізінде техникалық әрекетті төлем алынатын қоңырауларға немесе жөнелтілім бірліктеріне түрлендіріңіз.
- Пайдалануға байланысты емес төлемдерді қосыңыз. Қолданылатын жазылымды, ең төменгі міндеттемені, қосымша қызметтерді және іске асыру немесе пайдалану шығындарын енгізіңіз.
Бір іздеу үшін бір бақылау нөмірі қолданылатын қарапайым polling интеграциясы үшін бастапқы бағалау:
Іздеу сұраулары = бақыланатын жөнелтілімдер × орташа бақылау күндері × тәуліктегі іздеулер
Бұл қысқартылған формула әр жөнелтілім бірдей орташа кесте бойынша жүреді деп есептейді. Дәлірек модель әр жөнелтілім немесе жөнелтілім тобы бойынша сұрауларды қосып, кейін тіркеу қоңыраулары мен басқа төлем алынатын әрекеттерді енгізеді. Егер жөнелтілімдер ай соңынан кейін де белсенді болса, олардың сұрауларын сол сұраулар орындалған есеп айырысу кезеңдеріне бөліңіз.
Практикалық мысал: арзанырақ модель қашан өзгереді
Келесі сандар тек есептеуді көрсету үшін ойдан шығарылған. Олар 17TRACK бағалары, жеткізуші ұсыныстары немесе нарықтық эталондар емес.
Бір модельденген кезең ішінде 10 000 сәлемдеме тіркеліп, толық бақыланады деп алайық. Әрқайсысына бір тіркеу сұрауы және сегіз күн бойы күніне үш іздеу сұрауы қажет. Әр сұрау ақылы, әр сұрау бір сәлемдемеге қатысты және қайта жіберулер, пакет жеңілдіктері, лимиттер немесе тұрақты төлемдер жоқ деп есептейік.
- Тіркеу сұраулары: 10 000.
- Іздеу сұраулары: 10 000 × 8 × 3 = 240 000.
- Барлық төлем алынатын сұраулар: 250 000.
- Мысалдық қоңырау бойынша тариф: $0.002.
- Мысалдық жөнелтілім бойынша тариф: $0.04, қажетті мониторингті қоса алғанда.
Қоңырау бойынша пайдалану құны 250 000 × $0.002 = $500. Жөнелтілім бойынша пайдалану құны 10 000 × $0.04 = $400. Осы болжамдар бойынша жөнелтілім бойынша баға пайдалану үшін $100-ға арзанырақ.
Енді тек іздеу жиілігін күніне бір ретке өзгертейік. Сұраулар саны 10 000 тіркеу және 80 000 іздеу, яғни 90 000 қоңырау болады. Қоңырау бойынша пайдалану құны $180-ға түседі, ал мысалдық жөнелтілім бойынша пайдалану құны $400 болып қалады. Таңдалатын модель жұмыс жүктемесі өзгергендіктен өзгереді, баға құрылымдарының біреуі табиғи түрде жақсы болғандықтан емес.
Залалсыздық нүктесін табыңыз
Екі жоспарда да тұрақты төлемдер, лимиттер немесе қосымша ақылар болмаса, мына формуланы пайдаланыңыз:
Бір жөнелтілімге шаққандағы залалсыздық төлем алынатын қоңыраулар саны = жөнелтілім тарифі ÷ қоңырау тарифі
Мысалда $0.04 ÷ $0.002 = бір жөнелтілімге 20 төлем алынатын қоңырау. 20-дан жоғары болса, жөнелтілім ақысы төмен; 20-дан төмен болса, қоңырау ақысы төмен. Мысалдағы болжамдарға сәйкес тіркеу қоңыраулары да осы шекке кіреді.
Бұл қысқарту сатылы жоспарларға, алдын ала төленген кредиттерге, әртүрлі endpoint тарифтеріне немесе ең төменгі міндеттемелерге жеткіліксіз. Мұндай ұсыныстар үшін негізгі бірлік тарифтерін ғана салыстырмай, әр болжамды көлем бойынша толық шотты есептеңіз.
Webhooks polling-ті азайтуы мүмкін, бірақ есеп айырысуды бәрібір тексеру қажет
Polling дегеніміз — қолданбаңыздың бақылау ақпаратын қайта-қайта сұрауы. Webhook қызметке оқиғаны қолданбаңызға жіберуге мүмкіндік береді, сондықтан оқиғалар ағыны талаптарыңызға сай болса, қайталама іздеулер қажеттілігі азаяды.
Алайда іздеу сұрауларының азаюы шоттың автоматты түрде төмендеуін білдірмейді. Webhook жеткізуі қамтылған-қамтылмағанын, жеткізулер немесе қайта жіберулер есептеле ме, әрі сәйкестендіру үшін іздеулер әлі қажет пе — соны растаңыз. Қолданбаңыз қайталанатын немесе ретсіз келген оқиғаларды қауіпсіз өңдеп, жеткізу сәтсіздіктерінен қалпына келе алуы керек.
Тағы бір маңызды айырмашылық бар: ақпаратты жиірек сұрау негізгі тасымалдаушының жаңа сканерлеу жазбасын жасағанына кепілдік бермейді. Операциялық құндылығы аз polling жиілігіне ақы төлемес бұрын, іздеу нені қайтаратынын және деректердің қалай жаңартылатынын сұраңыз.
Негізгі тариф жасыруы мүмкін шығындар
Қамтылған лимиттер, ең төменгі төлемдер және алдын ала төленген қалдықтар
Ең төменгі шотты қамтылған пайдалануы бар жазылымнан ажыратыңыз. Ең төменгі шот шығынның төменгі шегін белгілеуі мүмкін; лимит артық пайдалану ақысы алынғанға дейін белгілі бір көлемді жабуы мүмкін. Алдын ала төленген кредиттер жарамдылық мерзімі, қайтарымдар және пайдаланылмаған қалдықтарға қатысты бөлек сұрақтар туындатады.
Лимит артық пайдалануға дейін шегерілетін жоспар үшін пайдалы құрылым:
API шоты = жоспардың тұрақты ақысы + төлем алынатын артық пайдалану + қолданылатын қосымша қызметтер
Бұл формуланы келісімшартқа сәйкес келсе ғана қолданыңыз. Бір қамтылған пайдалануды екі рет қоспаңыз және барлық жоспар шекті тарифті бірдей қолданады деп ойламаңыз.
Ұзақ уақыт жүретін жөнелтілімдер және қайталама тіркеулер
Ұзақ мониторинг кезеңдері polling құрылымында іздеу көлемін арттырады. Жөнелтілім бойынша бағада маңызды сұрақ — бастапқы ақы осы ұзақтықты қамти ма. Тек жылдам аяқталатын жеткізілімдерді емес, ерекше және кешіктірілген жөнелтілімдерді де тексеріңіз.
Сол бақылау нөмірі екінші рет жіберілгенде, түзетілгенде, өшіріліп қайта қосылғанда немесе басқа тасымалдаушымен байланыстырылғанда не болатынын да растаңыз. Қажет болса, қайталанудың алдын алуды іске асырыңыз, бірақ қолданба деңгейіндегі қайталануды жою жеткізушінің есеп айырысу идентификациясымен толық сәйкес келеді деп ойламаңыз.
Тарифтік шектеулер және ең жоғары өткізу қабілеті
Қолжетімді айлық лимит интеграцияның үлкен импортты немесе трафиктің күрт өсуін өңдей алатынын білдірмейді. Сұрау жылдамдығының шектерін, пакет лимиттерін, бір мезгілдегі орындау шектеулерін және шекке жеткен кездегі күтілетін әрекетті тексеріңіз. Айлық көлемге сай болғанымен, қажетті жұмыс процесін қолдамайтын жоспар тең дәрежелі балама емес.
Инженерлік және пайдалану шығындары
API шотын иеленудің жалпы құнынан бөлек ұстаңыз. Ішкі шығындарға интеграцияны әзірлеу, webhook хостингі, кезектер, мониторинг, инциденттерге жауап беру, деректерді сақтау және техникалық қызмет көрсету кіруі мүмкін.
Еңбек пен инфрақұрылым бойынша өз бағалауларыңызды пайдаланыңыз. Қымбатырақ жазылым операциялық жұмысты айтарлықтай азайтатыны дәлелденсе, бәрібір тиімді болуы мүмкін, бірақ бұл үнемді болжам емес, тексеру керек.
Коммерциялық ұсыныстарды қалай салыстырып, қысқа тізімді тексеру керек
Әр жеткізушіден бірдей жұмыс жүктемесінің сипаттамасын бағалауды сұраңыз: сәлемдеме көлемі, жөнелтілім құрамы, мониторинг ұзақтығы, жаңарту талаптары, endpoint-тер, ең жоғары жүктеме және қажет қызметтер. Есеп айырысу бірлігі туралы жазбаша түсіндірме мен үлгі шот есептеуін сұраңыз.
17TRACK-ті қарастыратын топтар үшін ресми Tracking API беті және API құжаттамасы өнім мен интеграцияны бағалаудың бастапқы нүктелері болып табылады. Болжамыңызға модель енгізбес бұрын, қолданылатын баға мен есеп айырысу анықтамаларын тікелей растаңыз. Бұл мақала қазіргі 17TRACK жоспарына баға бермейді және оны санатқа бөлмейді.
Міндеттеме қабылдамас бұрын, өкілдік жөнелтілімдерді пайдаланып бақыланатын пилоттық сынақ өткізіңіз. Бөлінген тапсырыстарды, қайталанатын жіберулерді, кешіктірілген сәлемдемелерді, трансшекаралық тасымалдарды және есеп айырысу шекарасынан өтетін жөнелтілімдерді қосыңыз. Сәтсіздік немесе қайталап жіберу әрекетін тек қызмет рұқсат ететін тәсілдермен ғана тексеріңіз.
- Сұрау журналдарын жеткізушінің пайдалану жазбаларымен салыстырыңыз.
- Тіркелген бақылау бірліктерін есептелген жөнелтілім бірліктерімен сәйкестендіріңіз.
- Қажетті жаңарту жиілігі іс жүзінде орындалып жатқанын тексеріңіз.
- Ең жоғары сұранысты айлық тұтынудан бөлек өлшеңіз.
- Шығындарды болжаудан бұрын түсіндірілмеген айырмашылықтарды зерттеңіз.
Кемінде үш болжам жасаңыз: қалыпты операциялар, маусымдық шарықтау және ұзаққа созылған транзит. Шотқа ерікті пайыз қоспай, негізгі факторларды өзгертіңіз. Мысалы, шарықтау кезеңі үшін сәлемдемелер санының артуын, ал кідіріс сценарийі үшін мониторинг ұзақтығының ұзаруын модельдеңіз.
Қай модельді таңдау керек?
Қоңырау бойынша бағаны таңдаңыз, егер іздеулер сирек орындалса, сұрау қажеттілігін өлшеуге болса және тіркеулер мен басқа төлем алынатын әрекеттерді қосқаннан кейін болжам залалсыздық нүктесінен төмен қалса. Жиі polling немесе болжанбайтын мониторинг ұзақтығы сұрау шығынын едәуір арттырса, бұл модельдің тартымдылығы төмендейді.
Жөнелтілім бойынша бағаны таңдаңыз, егер үздіксіз мониторинг қажет болса және ұсынылған жөнелтілім ақысы сізге керек жаңарту жиілігін, бақылау ұзақтығын және жеткізу механизмін қамтыса. Сирек пайдаланылатын мониторингке ақы төлесеңіз немесе жөнелтілім анықтамасы күтпеген қосымша бірліктерді тудырса, бұл модельдің тартымдылығы төмендейді.
Соңғы шешім бір операциялық сәлемдемеге шаққандағы жалпы шығынды пайдалануы керек: API шоты мен оған жатқызылатын операциялық шығындарды бизнесіңіз бақылауы тиіс бірегей сәлемдемелер санына бөліңіз. Жеткізушілер әртүрлі есеп айырысу бірліктерін қолданса да, ұсыныстардың барлығында ішкі сәлемдеме анықтамасын бірдей ұстаңыз.
Жиі қойылатын сұрақтар
Сәтсіз API сұраулары үшін ақы алына ма?
Екі нұсқаның ешқайсысын алдын ала қабылдамаңыз. Валидация қателерінің, аутентификация сәтсіздіктерінің, тарифтік шек жауаптарының, сервер қателерінің және тайм-ауттардың қалай есептелетінін сұраңыз. Тайм-аут қолданбаңыз оны қайта жібергенге дейін сұраудың өңделген-өңделмегеніне қатысты белгісіздік те тудыруы мүмкін.
Бір тапсырыс әрқашан бір жөнелтілім болып есептеле ме?
Жоқ. Бір тапсырыста бөлек бақыланатын бірнеше сәлемдеме болуы мүмкін. Бюджеттеу үшін тапсырыстарды бақылау бірліктерімен сәйкестендіріп, кейін жеткізушінің анықтамасын қолданыңыз. Қайтарымдар, ауыстырулар және тасымалдаушы ауысуы қалай есептелетінін растаңыз.
Пакет сұраулары шотымды азайта ма?
Есеп айырысу ережелері пакеттеуді ынталандырса ғана. Пакеттер желілік сұрауларды азайтуы мүмкін, бірақ төлем алынатын бақылау бірліктерін азайтпауы ықтимал. Пакет лимитін және есеп айырысу бір сұрау бойынша, бір элемент бойынша немесе салмақталған бірлік арқылы жүргізіле ме — тексеріңіз.
Webhooks барлық іздеу сұрауларын жоя ала ма?
Олар күнделікті polling-тің көп бөлігін жоюы мүмкін, бірақ жобалауыңызға бастапқы алу, өткізіп алған оқиғалардан кейін қалпына келу немесе мерзімді сәйкестендіру әлі де қажет болуы ықтимал. Бұл қоңырауларды бағалауға қосып, webhook жеткізуі үшін қандай да бір ақы бар-жоғын растаңыз.
Келесі айда әлі белсенді болатын жөнелтілімдерге бюджетті қалай жоспарлау керек?
Қоңырау бойынша бағада сол жөнелтілімдер келесі кезеңде жасайтын сұрауларды болжаңыз. Жөнелтілім бойынша бағада мониторинг қамтыла ма немесе қайта ақы алына ма — соны растаңыз. Ағымдағы жұмыс көлемін бағалағанда тек жаңадан жасалған жөнелтілімдерді санамаңыз.
Дереккөздер
Жоғарыдағы есептеулер жарияланған жеткізуші бағаларына емес, нақты гипотетикалық кіріс деректеріне негізделген. 17TRACK бағалауы үшін осы ресми анықтамалық беттерді пайдаланып, коммерциялық талаптарды тікелей растаңыз:
