Πώς λειτουργούν ο εντοπισμός και οι μεταθέσεις

1) Τι είναι S2S και γιατί χρειάζεται

(server-to-server) παρακολούθηση είναι η ανταλλαγή των γεγονότων μεταξύ των διακομιστών της πηγής κυκλοφορίας (ο ανακατευθυντής/ανιχνευτής/δίκτυο σας) και των διακομιστών του χειριστή (καζίνο), χωρίς εξάρτηση από τα cookies και τις κλειδαριές του προγράμματος περιήγησης.

Postback - ένα απερχόμενο αίτημα HTTP με ένα γεγονός (reg/KYC/FTD/2nd_dep/...) από το backend του αποστολέα στο URL του παραλήπτη.

Πλεονεκτήματα:

Τα δεδομένα δεν χάνονται λόγω του adblock/ITP/ιδιωτικού τρόπου.
Μεγαλύτερη ακρίβεια της κατανομής και της ποιότητας της τιμολόγησης.
Μπορείτε να μεταφέρετε με ασφάλεια το ποσό/νόμισμα και τις σημαίες υπηρεσίας.

2) Βασική αλυσίδα και ρόλοι

1. Κάντε κλικ: ο χρήστης κάνει κλικ στη διαφήμιση → ο αναπροσανατολιστής σας δημιουργεί ένα 'κλικ _ id' και καταγράφει τις παραμέτρους (utm, geo, συσκευή, sub_id).

2. Ανακατευθύνετε: ο χρήστης πηγαίνει στην προσγείωση του χειριστή, το 'click _ id' σπρώχνεται στο URL ή κρυπτογραφείται.

3. Καταχώριση/CCM/καταθέσεις πραγματοποιούνται στον φορέα εκμετάλλευσης.

4. Postbacks: ο εξυπηρετητής του χειριστή στέλνει 'εγγραφή', 'kyc _ εγκεκριμένο', 'deposit _ success', κλπ. γεγονότα στον ανιχνευτή σας, δεσμεύοντάς τα στο πρωτότυπο 'click _ id'.

5. BI/Reporting: συγκεντρώνετε γεγονότα σε τμήματα UTM/creative/geo/devices, σκεφτείτε CPA/ROAS/LTV.

Σύστημα κειμένου:


Το Ad → Click → [Ο αναπροσανατολιστής σας παράγει click_id] → LP/App →
↑             │
Εκ των υστέρων ( )

3) Αναγνωριστικά γεγονότων και σύνδεση

(υποχρεωτικό) - μοναδική ταυτότητα της πρώτης αφής· κλείδα κατανομής.

(κίτρινο) - μοναδική ταυτότητα κάθε γεγονότος (για ιδιοτέλεια).

(χονδρική) - Ταυτότητα παίκτη στην πλευρά του φορέα εκμετάλλευσης (διαβιβάζεται μόνο στο S2S).

(χονδρική) - για την ανάλυση UX/ταχύτητα.

τμήματα για την ανάλυση.

Κανόνας: click_id δημιουργείται από εσάς. ο φορέας εκμετάλλευσης αποθηκεύει στο πλευρό του τη χαρτογράφηση «click _ id ↔ user/account».

4) Πεδία γεγονότων: ελάχιστη σύνθεση

4. 1. Καταχώριση

json
{
"γεγονός": "καταχώριση", "event_id":" reg_8f9... "," click_id": "clk_123...," "account_id":" u_456... "," geo ":" BR "," συσκευή ":" android "," ts_event": "2025-10-21T14:54:12Z," "ip": "203. 0. 113. 7», «ua»: «Mozilla/5. 0", "υπογραφή": "hmac_sha256 (ωφέλιμο φορτίο)"
}

4. 2. Εγκεκριμένο KYC

json
{
"event": " " " :"  "" : " "  " :"  " " : " "  " :" basic "    πλήρης «,» υπογραφή «:»..
}

4. 3. Κατάθεση (FTD/Επανάληψη)

json
{
«event»: « » « :»  «» : « » « » : « » «ποσό»: 100. 00, "νόμισμα": "USD", "is_ftd": αλήθεια ", payment_method": "κάρτα    pix    crypto    πορτοφόλι», «ts_event": «2025-10-21T15:12:31Z,» «υπογραφή»: «..»
}

Τα απαιτούμενα πεδία είναι «event», «event _ i ,» click _ i , «ts _ event» (UTC), «signature».

Τα νομισματικά πεδία είναι πάντα μαζί με το «currency» (ISO-4217) και ως αριθμοί, όχι συμβολοσειρές.

5) Ασφάλεια: Υπογραφές και πρόσβαση

(HMAC-SHA256): «υπογραφή = HMAC (μυστικό, )», αγιοποιούν τη σειρά πεδίου → τη σταθερή επικύρωση.

Βραχύβιες μάρκες (JWT/αδιαφανείς) σε επίπεδο έγκρισης: TTL 5-15 λεπτά.

Ταυτότητα: Η επανάληψη του POST με το ίδιο 'event _ id' θα πρέπει να αποφέρει '200 OK' χωρίς διπλό.

Επιτρεπόμενη λίστα IP και mTLS (εάν είναι δυνατόν) στο prod.

Περιορισμός του ρυθμού: Προστατέψτε το τελικό σημείο από «εκρήξεις» και ρομπότ.

Απαγόρευση ανακατευθύνσεων HTTP από το τελικό σημείο μετά τον τοκετό. μόνο άμεσες απαντήσεις.

6) Αξιοπιστία: Retrays, ουρές και τάξη

Αναμονή (Kafka/RabbitMQ/SQS) μεταξύ λήψης γεγονότων και επεξεργασίας αναφορών - έτσι ώστε να μην χάνονται δεδομένα στις κορυφές.

Retrai με εκθετική παύση και οπισθοδρόμηση? όριο προσπαθειών και DLQ (ουρά αναμονής νεκρών γραμμάτων).

Η σειρά είναι προαιρετική, αλλά είναι επιθυμητό να υπάρχει «ts _ event» για διαλογή στη ΔΙ.

Αρχεία καταγραφής αιτήσεων/απαντήσεων (χωρίς ευαίσθητα δεδομένα), συσχέτιση με το «event _ id».

7) Χρονικές ζώνες, νόμισμα και συνέπεια

Σφραγίδες παντός χρόνου σε UTC ('2025-10-21T15: 12: 31Z').

Στις εκθέσεις προσδιορίζεται η χρονική ζώνη του έργου, αλλά αποθηκεύονται οι εκδηλώσεις στην UTC.

Αποθηκεύουν τα ποσά στο νόμισμα συναλλαγής και τα αναπαράγουν στο νόμισμα αναφοράς με αξιόπιστο επιτόκιο (FX βάσει ημερομηνίας).

8) Αποθάρρυνση και επιχειρηματικοί κανόνες

Ιδιαιτερότητα: Επαναλάβετε «ήδη επεξεργασμένη».

Αφαίρεση από (click_id + τύπος γεγονότος + ts-παράθυρο) ως εφεδρικός μηχανισμός.

Κανόνες εγκυρότητας FTD: ελάχιστη κατάθεση, μηδενική «μηδενική» αναπλήρωση· Ορίστε στο συμβόλαιο.

Η χρέωση/επιστροφή είναι ξεχωριστά γεγονότα «αρνητικού εισοδήματος» για μια έντιμη NGR.

9) Εμπιστευτικότητα και συμμόρφωση

Μην περάσετε το PII στο URL και εμπρός. είναι ένα μέρος για ευαίσθητα πεδία.

Αποθηκεύεται η συγκατάθεση (analytics/ads) και η έκδοσή τους.

Ελαχιστοποίηση πεδίων: μόνο ό, τι χρειάζεται για την απόδοση και την τιμολόγηση.

Τακτική επανεξέταση των λογιστικών πολιτικών διατήρησης.

10) Web2App και κινητή πραγματικότητα

Για εφαρμογές, συνδέστε το 'click _ i ' install _ id 'στην πλευρά MMP/SDK.

Όταν δεν υπάρχει deterministic ID (iOS privacy) - χρησιμοποιήστε ένα πιθανοληπτικό match + server κανόνες, και S2S παραμένει η «αλήθεια» για τιμολόγηση.

11) Παρακολούθηση και SLA

Μετρήσεις:

Επιτυχείς/εσφαλμένες μεταθέσεις (%/min), καθυστέρηση p95, αναλογία των επαναδρομολογήσεων, αναλογία των αντιγράφων.
Διαφορά γεγονότων μεταξύ των μερών (χειριστής έναντι ιχνηλάτη) την ημέρα.
Καθυστέρηση παράδοσης (καθυστέρηση κατάποσης) και «αποτυχίες» με την ώρα.

SLA (παράδειγμα):

Διαθεσιμότητα λήψης μετά την επιστροφή 99 ευρώ. 5 %/μήνα
Η μέση καθυστέρηση πριν από την εγγραφή στο DWH ≤ 60 δευτερόλεπτα. p95 απόκριση API ≤ 500 ms.
Αποσυγχρονισμός δεδομένων> 3% → υποχρεωτική αντιστοίχιση ακατέργαστων κορμών εντός 5 εργάσιμων ημερών.

12) Κατάλογοι ελέγχου

12. 1. Έλεγχος τεχνολογίας πριν από την εκτόξευση

Ανακατευθυντής με click_id γενιά και κορμούς.
Postback find point: TLS, HMAC, JWT, IP list, idempotency.
Τεκμηριώνονται τα συστήματα ωφέλιμου φορτίου και η κανονική επιτόπια εντολή.
Ουρές αναμονής + DLQs, Retrays, Error/Daily Alerts.
ώρα UTC, νόμισμα ISO, κανόνες FTD/επιστροφή/χρέωση.
Εκτελείται σε αμμοκιβώτιο με κούτσουρα αναφοράς στερέωσης.

12. 2. Έλεγχος λειτουργίας (κάθε εβδομάδα)

Συμφωνία του «φορέα εκμετάλλευσης ↔ ιχνηλάτη» με τον όγκο των γεγονότων και των ποσών.
Ανάλυση διπλών και «χαμένων» γεγονότων. τον έλεγχο των retrays.
Ελέγχει κλειδιά/μάρκες, διάρκεια ζωής και περιστροφή.
Εξέταση συμβάντων και προσαρμογή κανόνων.

13) Συχνά λάθη και τρόπος αποφυγής τους

1. Καμία ταυτότητα → αντιγράφων FTD σε Retrays. → Εισάγετε 'event _ id' και αποθηκεύστε το «seen».

2. Διαφορετικές ζώνες ώρας → «επιπλέουσες» D0/D1. → Πάντα UTC στο ημερολόγιο εκδηλώσεων.

3. Άθροισμα συμβολοσειρών/σφάλματα ανάλυσης. Αριθμοί διέλευσης με περίοδο και νόμισμα ISO.

4. Η υπογραφή στο «ακατέργαστο» JSON σπάει από τη σειρά των κλειδιών.

5. Δεν υπάρχουν DLQ/Retrays → Απώλεια γεγονότων στα Microsobes. → Αναμονή + εφεδρική + ειδοποίηση.

6. Αδύνατη ταυτοποίηση → πλαστών γραμματοσειρών. → λίστα HMAC + JWT + mTLS/IP.

7. Έλλειψη κανόνων FTD → διαφορές τιμολόγησης → Καθορισμός των ορισμών της σύμβασης.

14) Δειγματοληπτικά αιτήματα και απαντήσεις

14. 1. POST/postback (χειριστής-ιχνηλάτης)


POST/postback HTTP/1. 1
Τύπος περιεχομένου: εφαρμογή/json
Άδεια: Bearer eyJhbGciOi...
Υπογραφή X: sha256 = ab12...

{"event": "deposit _ succes ," event _ id ":" dep _ 9aa ","  "" ποσό ": 100. 00, «νόμισμα «: «USD»,» is _ ft : true», « »}

Απάντηση:


200 OK
{«status»:» ok», «idempotent»: false}

Επανάληψη με το ίδιο 'event _ id':


200 OK
{«status»:» ok», «idempotent»: real}

14. 2. Σφάλμα υπογραφής


403 Απαγορευμένο
{«σφάλμα «: «υπογραφή _ άκυρη», «υπόδειξη «:» έλεγχος κανονικής εντολής»}

15) Περιστατικά και ανάλυση

Σύμπτωμα: ο χειριστής έχει FTD = 120, έχετε 117.

Σχέδιο:

1. Συμφωνία χρονοδιαγράμματος (UTC) και νομισμάτων.

2. Εκφόρτωση ακατέργαστων αρχείων καταγραφής με 'event _ i /' click _ id'.

3. Αναζήτηση απορριφθέντων σημάτων/ταυτότητας λόγω υπογραφής/TTL.

4. Πρόσθετη παράδοση «κολλημένων» γεγονότων από το DLQ, πράξεις συμφιλίωσης.

16) Σχέδιο εφαρμογής

0-30 ημέρες - MVP κυκλώματος

Επαναπροσανατολιστής εκτόξευσης με 'κλικ _ id' και αρχεία καταγραφής.

Εφαρμογή της λήψης των ταχυδρομικών επιστροφών: HMAC, JWT, idempotency, queues, DLQ, alerts.

Ανυψώστε το αμμοκιβώτιο, εκτελέστε το σενάριο reg/FTD από το τέλος έως το τέλος με τις ποσότητες δοκιμής.

Σχηματικά πεδίων εγγράφων και αγιοποίηση.

31-60 ημέρες - Ποιότητα και κλίμακα

Συμπεριλαμβάνονται τα νομισματικά γεγονότα και η λογιστική διπλού νομίσματος (txn & report).

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

Υπογραφή διαδικασιών SLA/συμβάντων. προσθήκη συμβάντων χρέωσης/επιστροφής χρημάτων.

Στην BI, συλλέγουν προβολές: FTD, Payback D7/D30 ARPU.

61-90 ημέρες - Βιωσιμότητα και έλεγχος

Εισάγετε την εναλλαγή μυστικών/πιστοποιητικών, δοκιμές ανοχής βλάβης.

Εκτελούνται δοκιμές φορτίου και «ασκήσεις έκτακτης ανάγκης» (σταγόνα αναμονής/DB).

Τυποποίηση των βιβλίων αναπαραγωγής συνδυασμού και τριμηνιαίος έλεγχος των συστημάτων/κανόνων FTD.

17) Η τελική γραμμή

Η ανίχνευση είναι η «ραχοκοκαλιά» της έντιμης απόδοσης και τιμολόγησης: ως το κύριο κλειδί, προστατευμένα postbacks, idempotency, retrays και αυστηρή υγιεινή χρόνου/νομίσματος. Προσθέστε σε αυτό το διαφανές FTD κανόνες εγκυρότητας, γεγονότα φόρτισης και ώριμη παρακολούθηση - και μπορείτε να πάρετε ένα αξιόπιστο σύστημα όπου κάθε μετατροπή επιβεβαιώνεται από τον εξυπηρετητή και συγκλίνει σε αναφορές σε ένα λεπτό.