Streaming Token Accounting σε μια πύλη AI API: Τελική χρήση, ακυρώσεις και μερικές αποκρίσεις

Οι απαντήσεις ροής LLM είναι εύκολο να γίνουν πληρεξούσιοι και δύσκολο να χρεωθούν σωστά. Εάν μια πύλη API AI προωθεί συμβάντα που αποστέλλονται από τον διακομιστή στον πελάτη αλλά αντιμετωπίζει τα πρώτα κομμάτια ως εγγραφή χρήσης, τα αναλυτικά στοιχεία μισθωτή θα μετακινηθούν. Η μετατόπιση εμφανίζεται συνήθως σε διαφωνίες όπως: "ο χρήστης είδε μόνο τη μισή απάντηση", "ο πάροχος τιμολόγησε περισσότερα από όσα δείχνει ο πίνακας ελέγχου μας", "το όριο κυκλοφόρησε πολύ νωρίς" ή "ένα χρονικό όριο που παρήγαγε διακριτικά αλλά δεν υπήρχε γραμμή τιμολογίου".

Το βασικό πρόβλημα είναι ότι οι κλήσεις με ροή δεν είναι ένα συμβάν. Είναι μια ακολουθία: το αίτημα έγινε αποδεκτό, η ροή ανοδικής ροής άνοιξε, τα byte παραδόθηκαν, η τελική χρήση αναφέρθηκε, ο πάροχος διακόπηκε, ο πελάτης αποσυνδέθηκε, το χρονικό όριο της πύλης έληξε και η χρέωση διευθετήθηκε. Μια αξιόπιστη πύλη θα πρέπει να μοντελοποιεί αυτές τις καταστάσεις ρητά αντί να υποθέτει ότι μια ολοκληρωμένη απόκριση HTTP είναι η μόνη επιτυχημένη διαδρομή.

Η λειτουργία αποτυχίας: η ροή κρύβει το λογιστικό όριο

Οι ολοκληρώσεις χωρίς ροή συνήθως επιστρέφουν ένα αντικείμενο απόκρισης με μεταδεδομένα χρήσης. Μια πύλη μπορεί να ομαλοποιήσει αυτή τη χρήση, να γράψει μια σειρά καθολικού, να ενημερώσει το όριο και να εκπέμψει αναλυτικά στοιχεία με ένα πέρασμα.

Η ροή αλλάζει τα όρια. Η εμπειρία χρήστη είναι σταδιακή, αλλά η αλήθεια χρέωσης μπορεί να φτάσει στο τέλος, σε ένα τελικό συμβάν για συγκεκριμένο πάροχο, σε ένα αθροιστικό δέλτα, μέσω μιας συγκεντρωτικής απόκρισης SDK ή αργότερα μέσω των API αναφοράς παρόχου. Εάν ο πελάτης αποσυνδεθεί πριν από το συμβάν τελικής χρήσης, η πύλη μπορεί να έχει παραδώσει μόνο μέρος της απάντησης ενώ ο πάροχος εξακολουθεί να δημιουργεί και να χρεώνει περισσότερα διακριτικά.

Γεγονός: Το OpenAI τεκμηριώνει ότι οι καλούντες ροής που θέλουν δεδομένα χρήσης θα πρέπει να ορίσουν stream_options με include_usage. Το OpenAI παρέχει επίσης καταληκτικά σημεία χρήσης και κόστους σε επίπεδο οργανισμού, ενώ σημειώνει ότι η χρήση και το κόστος μπορεί να μην συμβαδίζουν πάντα τέλεια για οικονομικούς σκοπούς.

Γεγονός: Η Anthropic ροή χρησιμοποιεί συμβάντα που αποστέλλονται από τον διακομιστή, όπως message_start, content_block_delta, message_delta και message_stop. Οι πληροφορίες χρήσης του message_delta είναι αθροιστικές, επομένως μια πύλη δεν πρέπει να προσθέτει κάθε δέλτα χρήσης μαζί.

Γεγονός: Τα API ροής τύπου Gemini και Vertex μπορούν να εκθέσουν σταδιακά κομμάτια, ενώ τα SDK μπορεί επίσης να παρέχουν ένα αντικείμενο συγκεντρωτικής απόκρισης. Για τις πύλες, αυτή η συγκεντρωτική διαδρομή μπορεί να είναι καλύτερη πηγή για ολοκληρωμένη χρήση από τα ορατά κομμάτια μόνο.

Χρησιμοποιήστε ένα μηχάνημα κατάστασης ροής, όχι μια σημαία επιτυχίας boolean

Ένα αίτημα μετάδοσης ροής θα πρέπει να έχει σταθερό ιστορικό χρήσης πριν ξεκινήσει η κλήση προς τα πάνω. Αυτό το αρχείο θα πρέπει να κινείται μέσα από ρητές καταστάσεις. Ένα πρακτικό ελάχιστο είναι:

• αποδεκτό: η πύλη επαλήθευσε την ταυτότητα του κλειδιού, απέδωσε τον μισθωτή και δημιούργησε μια ανοιχτή σειρά καθολικού.
• first_byte_sent: τουλάχιστον ένα συμβάν εξόδου έφτασε στον μεταγενέστερο πελάτη.
• provider_completed: ο ανάντη πάροχος εξέπεμψε ένα κανονικό σήμα διακοπής ή ένα ολοκληρωμένο αντικείμενο απόκρισης.
• client_aborted: η κατάντη υποδοχή έκλεισε πριν από την κανονική ολοκλήρωση της πύλης.
• provider_error: ο πάροχος upstream επέστρεψε ένα σφάλμα μετά την έναρξη της ροής ή πριν από την άφιξη της τελικής χρήσης.
• gateway_timeout: η πύλη επέβαλε τον προϋπολογισμό του λανθάνοντος χρόνου και τερμάτισε το αίτημα.
• τακτοποιήθηκε: η πύλη μετέτρεψε τη χρήση σε κόστος μισθωτή και κατανάλωση ποσόστωσης.
• συμφιλιώθηκε: μεταγενέστερα δεδομένα χρήσης ή κόστους παρόχου επιβεβαίωσαν ή προσάρμοσαν τη σειρά.

Αυτό το μοντέλο αποτρέπει ένα κοινό σφάλμα αναλυτικών στοιχείων: επισήμανση κάθε ροής που παρήγαγε κείμενο ως "επιτυχής και ακριβής". Μια ροή μπορεί να είναι χρήσιμη για τον χρήστη, ημιτελής από τον πάροχο, εκτιμώμενη για χρέωση και εκκρεμής συμφωνία ταυτόχρονα.

Προτεινόμενα πεδία καθολικού

Διατηρήστε τη σειρά χρόνου αιτήματος μικρή αλλά σαφή:

{
  "request_id": "gw_req_...",
  "tenant_id": "tenant_123",
  "api_key_id": "key_456",
  "πάροχος": "openai|anthropic|gemini|...",
  "provider_request_id": null,
  "model": "provider-model-id",
  "state": "αποδεκτό",
  "ροή": αλήθεια,
  "input_tokens": null,
  "output_tokens_billed": null,
  "output_tokens_delivered_estimate": 0,
  "provider_usage_source": null,
  "billing_status": "εκκρεμεί_συμφωνία",
  "client_abort_at": null,
  "provider_completed_at": null,
  "settled_at": null,
  "error_class": null
}

Ο σημαντικός διαχωρισμός είναι output_tokens_billed έναντι output_tokens_delivered_estimate. Οι χρήστες ενδιαφέρονται για το τι έφτασε στην εφαρμογή τους. Τα οικονομικά ενδιαφέρονται για το τι τιμολόγησε ο πάροχος. Αυτοί οι αριθμοί μπορεί να διαφέρουν μετά από αποσυνδέσεις, ροές κλήσεων εργαλείων, κρυφά διακριτικά συλλογισμού, αποθηκευμένα διακριτικά, στάσεις ασφαλείας ή χρονικά όρια πύλης.

Κανόνες λήψης για συγκεκριμένο πάροχο

Ένα ουδέτερο από πάροχο API συμβατό με OpenAI είναι χρήσιμο για προγραμματιστές εφαρμογών, αλλά ο προσαρμογέας πύλης εξακολουθεί να χρειάζεται λογιστικούς κανόνες για συγκεκριμένους παρόχους.

OpenAI συμβατή ροή

Για διαδρομές OpenAI, εκθέστε μια επιλογή πύλης που επιτρέπει την αναφορά χρήσης ανάντη όπου υποστηρίζεται. Ένα κοινό μοτίβο είναι η αποδοχή μιας προεπιλογής σε επίπεδο πύλης όπως:

{
  "ροή": αλήθεια,
  "stream_options": {
    "include_usage": αληθές
  }
}

Εάν ο μεταγενέστερος καλούντος το παραλείψει, η πύλη μπορεί να αποφασίσει εάν θα το κάνει έγχυση για διαδρομές όπου αυτό είναι συμβατό. Τεκμηριώστε αυτήν τη συμπεριφορά, επειδή ορισμένοι πελάτες αναμένουν ακριβή συμβατότητα καλωδίων και ορισμένα μοντέλα ή upstream ενδέχεται να μην υποστηρίζουν την τελική χρήση με τον ίδιο τρόπο.

Σύσταση: μην διακανονίζετε το κόστος ενοικίασης από πρώιμα κομμάτια. Διατηρήστε τη σειρά του καθολικού ανοιχτή έως ότου καταγραφεί το τελικό συμβάν χρήσης, η απάντηση του παρόχου λήξει χωρίς χρήση ή η ροή εισέλθει σε μια διαδρομή σφάλματος ή ακύρωσης.

Ανθρωπική ροή

Η αθροιστική χρήση του Anthropic απαιτεί διαφορετικό κανόνα. Εάν μια πύλη δει τρία συμβάντα message_delta με πλήθος διακριτικών εξόδου 10, 25 και 40, ο αριθμός εξόδου είναι 40, όχι 75.

αφήστε το latestUsage = null;
for await (const event of anthropicStream) {
  if (event.type === "message_delta" && event.usage) {
    if (latestUsage && event.usage.output_tokens < lastUsage.output_tokens) {
      emit("cumulative_usage_regressed", requestId);
    }
    lastUsage = event.usage;
  }
  forwardToClient(γεγονός);
}
settleFromLatestCumulativeUsage(latestUsage);

Σύσταση: καταγράψτε την πιο πρόσφατη αθροιστική τιμή χρήσης και εκπέμπετε ένα συμβάν παρατηρητικότητας εάν υποχωρήσει. Μια παλινδρόμηση μπορεί να υποδεικνύει σφάλματα ανάλυσης, διπλότυπα συμβάντα, αλλαγές παρόχου ή μικτές ροές.

Ροή σε στυλ Gemini και Vertex

Το Gemini υποστηρίζει κομμάτια ροής για να μειώσει τον αντιληπτό λανθάνοντα χρόνο. Στα SDK τύπου Vertex, η ροή μπορεί να εκθέσει τόσο μια ασύγχρονη ροή όσο και ένα αντικείμενο συγκεντρωτικής απόκρισης. Μια πύλη θα πρέπει να διατηρεί αυτή τη συγκεντρωτική διαδρομή όταν είναι διαθέσιμη.

const streamingResult = await model.generateContentStream(request);
για αναμονή (συνεχές κομμάτι του streamingResult.stream) {
  forwardChunk(κομμάτι);
  countDeliveredBytesOrText(κομμάτι);
}
const aggregated = αναμονή streamingResult.response;
settleFromAggregatedUsage(συγκεντρωτικά);

Σύσταση: αποφύγετε τη δημιουργία όλης της λογιστικής από ορατά κομμάτια, εάν το SDK παρέχει μια ολοκληρωμένη εγγραφή απόκρισης. Τα κομμάτια είναι για καθυστέρηση. Το τελικό αντικείμενο είναι συχνά καλύτερο για τιμολόγηση και αναλυτικά στοιχεία.

Χειριστείτε τις αποσυνδέσεις πελατών ως λογιστικά συμβάντα πρώτης κατηγορίας

Οι αποσυνδέσεις πελατών είναι εκεί όπου πολλές πύλες χάνουν χρήματα ή υπερχρεώνουν τους πελάτες. Μια καρτέλα προγράμματος περιήγησης κλείνει, ένα δίκτυο κινητής τηλεφωνίας πέφτει ή μια εφαρμογή ακυρώνει ένα αίτημα. Η πύλη παρατηρεί ότι η υποδοχή κατάντη είναι κλειστή, αλλά ο πάροχος ανάντη ενδέχεται να εξακολουθεί να δημιουργεί.

Η πύλη θα πρέπει να κάνει μια ρητή επιλογή πολιτικής:

• Άμεση ακύρωση ανάντη: μειώνει τη σπατάλη παραγωγής και το κόστος παρόχου, αλλά μπορεί να διακόψει τις ροές εργασίας όπου το backend εξακολουθεί να χρειάζεται το αποτέλεσμα μετά την αποσύνδεση της διεπαφής χρήστη.
• Συνέχεια ανάντη στο παρασκήνιο: μπορεί να διατηρήσει την εργασία για καταναλωτές από τον διακομιστή, αλλά ο χρήστης μπορεί να μην βλέπει όλα τα διακριτικά που δημιουργούνται και χρεώνονται.
• Συμπεριφορά που εξαρτάται από τη διαδρομή: ακυρώστε για διαδραστική συνομιλία, συνεχίστε για ροές εργασίας που μοιάζουν με εργασία και κάντε τη ρύθμιση ορατή στους ενοικιαστές.

Μια πρακτική προεπιλογή για τη διαδραστική ροή είναι να ακυρώσετε το upstream όταν αποσυνδεθεί ο μεταγενέστερος πελάτης και μετά να επισημάνετε τη σειρά του καθολικού ως client_aborted. Εάν η τελική χρήση φτάσει κατά τη διάρκεια της ακύρωσης, συμβιβαστείτε από αυτήν την έγκυρη χρήση. Εάν όχι, επισημάνετε τη σειρά εκτιμώμενο ή pending_reconciliation αντί να προσποιηθείτε ότι είναι ακριβής.

downstream.on("close", async () => {
  if (!providerCompleted) {
    ledger.markClientAborted(requestId);
    await upstream.abort().catch(() => {
      ledger.emit("upstream_cancel_failed", requestId);
    });
  }
});

Σύσταση: εκθέστε διαφανείς ετικέτες χρέωσης, όπως τελική, provider_reconciled, εκτιμώμενο, απαλλαγμένο ή εκκρεμεί_συμφωνία. Αυτό είναι πιο υπερασπίσιμο από το να εμφανίζεται κάθε κλήση σε ροή ως αμέσως ακριβές.

Εφαρμογή ορίου κατά τη διάρκεια μιας ροής

Η ακριβής χρέωση εξαρτάται συνήθως από την τελική χρήση του παρόχου, αλλά η επιβολή του ορίου δεν μπορεί πάντα να περιμένει μέχρι το τέλος. Δεν θα πρέπει να επιτρέπεται σε έναν ενοικιαστή με σκληρό προϋπολογισμό να κάνει ροή επ' αόριστον, επειδή η ακριβής χρήση δεν είναι διαθέσιμη κατά τη διάρκεια της πτήσης.

Χρησιμοποιήστε δύο μηχανισμούς μαζί:

1. Κράτηση πριν από την πτήση: κρατήστε ένα εκτιμώμενο μέγιστο με βάση το μοντέλο, τα απαιτούμενα μέγιστα διακριτικά, την πολιτική ενοικίασης και το τρέχον υπόλοιπο.
2. Έλεγχοι πίεσης ροής: εκτιμήστε την παραδοθείσα έξοδο κατά τη διάρκεια της ροής και σταματήστε εάν το αίτημα υπερβεί ένα διαμορφωμένο όριο ασφαλείας.

Αυτός είναι ένας μηχανισμός ελέγχου, όχι ο τελικός λογαριασμός. Οι πάροχοι μπορεί να μετρούν τα αποθηκευμένα διακριτικά, τα διακριτικά συλλογιστικής, τα πολυτροπικά διακριτικά ή τα κρυφά διακριτικά διαφορετικά από τον εκτιμητή μιας πύλης.

Εναλλαγή: οι εκτιμήσεις σε πραγματικό χρόνο βοηθούν στην επιβολή των προϋπολογισμών, αλλά μπορεί να αποκλίνουν από τα διακριτικά που χρεώνονται από τον πάροχο. Ο τελικός διακανονισμός θα πρέπει να χρησιμοποιεί έγκυρη χρήση παρόχου όταν είναι διαθέσιμη και η συμφωνία θα πρέπει να προσαρμόζει τις εκτιμήσεις αργότερα.

Συμβάντα παρατηρητικότητας που εντοπίζουν σφάλματα λογιστικής

Οι αποτυχίες χρέωσης ροής διορθώνονται ευκολότερα όταν η πύλη εκπέμπει στοχευμένα συμβάντα αντί μόνο για γενικά αρχεία καταγραφής αιτημάτων. Προσθέστε συμβάντα όπως:

• final_usage_missing: η ροή έληξε χωρίς έγκυρη χρήση.
• cumulative_usage_regressed: ο αθροιστικός αριθμός διακριτικών μετακινήθηκε προς τα πίσω.
• stream_ended_without_stop_event: δεν παρατηρήθηκε κανονικός δείκτης διακοπής παρόχου.
• aborted_after_provider_completion: ο πάροχος ολοκλήρωσε, αλλά ο μεταγενέστερος πελάτης έκλεισε πριν ολοκληρωθεί η προώθηση της πύλης.
• settled_from_estimate: το καθολικό μισθωτή χρησιμοποίησε μια εκτίμηση επειδή η τελική χρήση δεν ήταν διαθέσιμη.
• reconciliation_adjusted_usage: η αναφορά παρόχου άλλαξε αργότερα τη σειρά.

Γεγονός: Οι σημασιολογικές συμβάσεις του OpenTelemetry GenAI συνιστούν τη χρήση πληροφοριών χρήσης που επιστρέφονται από τον πάροχο για απαντήσεις ροής όταν είναι διαθέσιμες και προειδοποιούν για την αναφορά μετρήσεων χρήσης εάν δεν είναι δυνατό να ληφθούν αποτελεσματικά ή με ακρίβεια οι μετρήσεις των διακριτικών.

Για αναλυτικά στοιχεία χρήσης AI, αυτό σημαίνει ότι οι πίνακες εργαλείων θα πρέπει να υποστηρίζουν επίπεδα εμπιστοσύνης. Ένα γράφημα που συνδυάζει τελικές, εκτιμώμενες και συμφωνημένες τιμές χωρίς ετικέτες μπορεί να φαίνεται καθαρό αλλά να παραπλανά τις ομάδες χρηματοδότησης και υποστήριξης.

Δοκιμές συμμόρφωσης για λογιστική ροής

Μην βασίζεστε σε μη αυτόματες δοκιμές με μια προτροπή συνομιλίας σε χαρούμενη διαδρομή. Κάθε προσαρμογέας παρόχου θα πρέπει να έχει δοκιμές συμμόρφωσης για τις περιπτώσεις που σπάνε τα καθολικά:

• Κανονική ροή: φτάνει η τελική χρήση, παρατηρείται διακοπή συμβάντος, το καθολικό καθορίζεται ως τελικό.
• Ροή κλήσης εργαλείου: προωθούνται τα δέλτα κλήσεων εργαλείων, καταγράφεται η χρήση, τα δομημένα μεταδεδομένα δεν καταστρέφουν την καταμέτρηση διακριτικών.
• Διακοπή ασφάλειας ή άρνησης: ο πάροχος σταματά νωρίς, η χρήση εξακολουθεί να ρυθμίζεται σωστά.
• Αναγκαστική αποσύνδεση πελάτη: κατάντη κλείνει μετά από μερική έξοδο. upstream ακυρώνεται ή συνεχίζεται σύμφωνα με την πολιτική.
• Upstream 5xx μετά από μερική έξοδο: η πύλη καταγράφει μερική παράδοση και δεν επισημαίνει το αίτημα ως καθαρό επιτυχημένο.
• Λήξη χρονικού ορίου πύλης πριν από την τελική χρήση: η σειρά γίνεται εκτιμώμενη ή εκκρεμεί συμφωνία.
• Λείπει τελικό συμβάν: ο προσαρμογέας εκπέμπει final_usage_missing και αποφεύγει τις ακριβείς ετικέτες χρέωσης.

Αυτές οι δοκιμές θα πρέπει να επιβεβαιώνουν μεταβάσεις κατάστασης, πεδία καθολικού, εκπεμπόμενα συμβάντα παρατηρησιμότητας και συμπεριφορά κατάντη. Η συμβατότητα ροής byte-for-byte δεν είναι αρκετή. οι λογιστικές παρενέργειες αποτελούν μέρος της σύμβασης.

Λίστα ελέγχου πρακτικής εφαρμογής

• Δημιουργήστε τη σειρά του καθολικού χρήσης πριν αποστείλετε το αίτημα ανάντη.
• Αποθηκεύστε αναγνωριστικά μισθωτή, κλειδιού, χρήστη, μοντέλου, διαδρομής, παρόχου και αιτήματος κατά την ώρα του αιτήματος.
• Ενεργοποιήστε την αναφορά τελικής χρήσης παρόχου όπου υποστηρίζεται, όπως stream_options.include_usage συμβατή με OpenAI.
• Για αθροιστικούς παρόχους, αποθηκεύστε την πιο πρόσφατη τιμή χρήσης αντί να αθροίζετε συμβάντα.
• Διατηρήστε τα συγκεντρωτικά αντικείμενα απόκρισης όταν τα SDK τα παρέχουν.
• Παρακολουθήστε την παραγωγή που παραδόθηκε ξεχωριστά από τη χρήση που χρεώνεται από τον πάροχο.
• Κατά την αποσύνδεση, ακυρώστε την ανάντη σύμφωνα με την πολιτική διαδρομής και επισημάνετε client_aborted.
• Χρησιμοποιήστε διαφανείς καταστάσεις χρέωσης: οριστική, εκτιμώμενη, εκκρεμής συμφωνία, ο πάροχος συμβιβάστηκε ή παραιτήθηκε.
• Εκπέμψτε συμβάντα παρατηρητικότητας ειδικά για λογιστική.
• Συμβιβαστείτε αργότερα με τις αναφορές χρήσης του παρόχου ή κόστους όταν είναι διαθέσιμες, διατηρώντας παράλληλα την απόδοση μισθωτή στο χρόνο αιτήματος.

Τι να δείξετε στους ενοικιαστές

Οι ενοικιαστές δεν χρειάζονται κάθε εσωτερική εκδήλωση, αλλά χρειάζονται ειλικρινείς ετικέτες. Ένας χρήσιμος πίνακας χρήσης μπορεί να εμφανίζει:

• Κατάσταση: τελική, εκτιμώμενη ή συμβιβασμένη.
• Αποτέλεσμα αιτήματος: ολοκληρώθηκε, ο πελάτης ματαιώθηκε, σφάλμα παρόχου ή λήξη χρόνου πύλης.
• Εξόδου που παραδόθηκε: κατά προσέγγιση κείμενο ή byte που αποστέλλονται στον πελάτη.
• Χρεωμένα διακριτικά: κανονικοποιημένη χρήση από τον πάροχο που χρησιμοποιείται για το κόστος.
• Προσαρμογή: κάθε μεταγενέστερο δέλτα συμφωνίας.

Αυτή η σχεδίαση μειώνει την ασάφεια υποστήριξης. Εάν ένας χρήστης είδε μόνο ένα μέρος μιας απόκρισης, ο πίνακας ελέγχου μπορεί να εξηγήσει εάν ο πάροχος είχε ήδη ολοκληρώσει, εάν η πύλη ακυρώθηκε προς τα πάνω και εάν η χρέωση είναι τελική ή εκτιμώμενη.

Προτάσεις έναντι προβλέψεων

Προτάσεις: αντιμετωπίζετε τα αιτήματα ροής ως μηχάνημα κατάστασης, περιμένετε την έγκυρη τελική χρήση πριν από την ακριβή διευθέτηση, διαχωρίστε την παράδοση παράδοσης από τη χρήση με χρέωση και επισημάνετε τις εκτιμώμενες σειρές με ειλικρίνεια. Οι προσαρμογείς παρόχου θα πρέπει να κωδικοποιούν τη σημασιολογία χρήσης για συγκεκριμένο πάροχο αντί να ισοπεδώνουν κάθε ροή σε έναν γενικό διακομιστή μεσολάβησης byte.

Πρόβλεψη: η λογιστική ροής θα γίνει πιο σημαντική καθώς τα μοντέλα αποκαλύπτουν περισσότερες κρυφές εργασίες: κουπόνια συλλογισμού, εκπτώσεις κρυφής μνήμης διακριτικών, πολυτροπική επεξεργασία, ίχνη χρήσης εργαλείων και στάσεις ασφαλείας. Οι πύλες που διαχωρίζουν ήδη τη χρήση που χρεώνεται από τον πάροχο από την έξοδο που είναι ορατή από τον πελάτη θα προσαρμοστούν πιο εύκολα από τις πύλες που μετρούν μόνο το κείμενο ροής.

Εκκίνητο συμπέρασμα

Εάν η πύλη σας υποστηρίζει ροή, ελέγξτε μία διαδρομή σήμερα: αναγκάστε την αποσύνδεση ενός πελάτη μετά τα πρώτα μερικά κομμάτια και επιθεωρήστε τη σειρά του καθολικού. Αν λέει "επιτυχία" με ακριβείς μετρήσεις διακριτικών, τα αναλυτικά στοιχεία σας είναι πιθανότατα ψέματα.

Η λύση είναι να μην εγκαταλείψετε τη ροή. Διατηρήστε τη γρήγορη εμπειρία χρήστη, αλλά κάντε ρητές λογιστικές καταστάσεις για την ολοκλήρωση της ροής, την ακύρωση, τα σφάλματα παρόχου, την έλλειψη τελικής χρήσης και τη συμφωνία. Αυτό δίνει στις ομάδες προϊόντων ανταποκρινόμενο αποτέλεσμα, στις ομάδες χρηματοδότησης υπερασπίσιμο κόστος και στις ομάδες υποστήριξης αρκετά στοιχεία για να εξηγήσουν τις μερικές απαντήσεις χωρίς να μαντέψουν.

Σχετική ανάγνωση

• σύνδεση ιχνών, λογιστικών βιβλίων καιδημιουργία σύμβασης συμβατότητας πύλης συμβατής με OpenAI