איך S2S מעקב ודואר עובד

1) מהי S2S ומדוע היא נחוצה

S2S (שרת אל שרת) היא החלפת אירועים בין השרתים של מקור התנועה (הכור/גשש/רשת) לבין השרתים של המפעיל (קזינו), ללא תלות בעוגיות ומנעולים בדפדפן.

Postback - בקשת HTTP יוצאת עם אירוע (reg/KYC/FTD/2nd_dep/...) מהקצה האחורי של השולח לכתובת המקבל.

יתרונות:

הנתונים לא אבדו עקב מצבי אדבלוק/ITP/פרטי.
דיוק גבוה יותר של ייחוס ואיכות החיוב.
אתה יכול לבטח להעביר סכום/מטבע ודגלי שירות.

2) שרשרת ותפקידים בסיסיים

1. לחיצה: המשתמש לוחץ על הפרסומת * הכוון שלך יוצר ”לחיצה _ id” ומחבר את הפרמטרים (אום, גיאו, התקן, sub_id).

2. כיוון מחדש: המשתמש עובר לנחיתה של המפעיל, "לחץ _ id' נדחף לכתובת או מוצפן.

3. ההרשמה/CCM/הפקדות מתרחשות במרכזייה.

4. postbacks: השרת של האופרטור שולח "רישום", "kyc _ אושר", "deposit _ success' וכו '.

5. BI/Reporting: אתה מצרף אירועים על פני קטעי UTM/creative/geo//paction, שקול CPA/ROAS/LTV.

ערכת טקסט:


Ad Lack # [ הכוון שלך יוצר click_id ] LP/App
↑             │
└──────── postback (S2S) ─┘

3) מזהים אירועים וחיבורים

click_id (חובה) - זיהוי ייחודי של המגע הראשון; מפתח ייחוס.

event_id (צהוב) - זיהוי ייחודי של כל אירוע (לאידמפוטנטיות).

user_id/ account_id (סיטונאי) - זיהוי שחקן בצד המפעיל (מועבר רק S2S).

session_id (בסיטונות) - לניתוח UX/מהירות.

aff_sub/campaign/ creative_id - חלקים לאנליטיקה.

כלל: click_id נוצר על ידך; המפעיל בצד שלו מאחסן את המיפוי 'לחץ _ id ↔ המשתמש/חשבון'.

4) שדות אירועים: הרכב מינימלי

4. 1. הרשמה

ג 'סון
{
”אירוע”: ”רישום”, ” ”: ” ”: ” ”: ” ”: ”גיאו”: 0. 113. 7,” ua ”:” Mozilla/5 ”. 0, ”חתימה”: ”hmac_sha256 (מטען)”
}

4. 2. אושר על ידי KYC

ג 'סון
{
”אירוע”: ” ” ” ”: ” ” ” ”: ” ”    מלא, "חתימה": "..
}

4. 3. הפקדה (FTD/חוזר)

ג 'סון
{
”אירוע”: ” ” ” ”: ” ”: ” ”: 00, ”מטבע”: ”USD”, ”is_ftd": נכון,” payment_method": ”כרטיס:”    פיקס (פיקס)    קריפטו קריפטו    ארנק, ”ts_event":” 2025-10-21T15:12:31Z, ”” חתימה ”:”..
}

שדות נדרשים הם ”אירוע”, ”אירוע _ id',” קליק _ id', ”ts _ event” (UTC), ”חתימה”.

שדות מטבע הם תמיד יחד עם 'currency' (ISO-4217) וכמספרים, לא מחרוזות.

5) אבטחה: חתימות וגישה

HMAC-SHA256: ”חתימה = HMAC (סוד, canonical_payload)”; סדר שדה קנוניזציה = אימות יציב.

אסימונים קצרי ימים (JWT/Opaque) ברמת האישור: TTL 5-15 דקות.

Idempotence: חזור על POST עם אותו "אירוע _ id' אמור להניב '200 OK' ללא כפולה.

IP Low-List ו-MTLS (במידת האפשר) על הפרוד.

קצב מגביל: הגן על נקודת סוף מפני ”התפרצויות” ורובוטים.

היובש של HTTP חוזר מקצה הפוסטבק; תשובות ישירות בלבד.

6) אמינות: מגשים מחדש, תורים וסדר

תור (Kafka/RabbitMQ/SQS) בין קבלת אירועים ועיבוד דיווחים - כדי לא לאבד נתונים בפסגות.

רטריי עם הפסקה אקספוננציאלית וג 'יטר אחורי; גבול הניסיונות ו-DLQ (תור אותיות מתות).

הסדר הוא אופציונלי, אבל רצוי שיהיה 'ts _ event' למיון ב-BI.

רישומי בקשה/תגובה (ללא נתונים רגישים), קורלציה על ידי "event _ id'.

7) אזורי זמן, מטבע ועקביות

חותמות כל הזמנים ב-UTC (2025-10-21T15: 12: 31Z).

בדו "חות, ציין את זמן הפרויקט, אך אחסן אירועים ב ־ UTC.

לאחסן את הסכומים במטבע העסקה ולשכפל אותם במטבע הדו "ח באמצעות שיעור אמין (FX מבוסס תאריך).

8) כפילות וחוקים עסקיים

event_id אידמפוטנטיות: חזור = ”כבר מעובד”.

Dauplication by (click_id + extence type + ts-window) כמנגנון נפילה.

חוקי תוקף על תנאי: הפקדה מינימלית, אין בונוס ”אפס” חידוש; לתקן בחוזה.

צ 'רג' בק/החזר הם אירועים נפרדים של הכנסה שלילית עבור NGR הגון.

9) סודיות וציות

אל תעביר את PII לכתובת וחזית; S2S הוא מקום לשדות רגישים.

סכימת אחסון (אנליטיקה/מודעות) וגרסה אותם.

למזער שדות: רק מה שנדרש לייחוס וחיוב.

סקירת מדיניות הרישום באופן קבוע.

10) Web2App ומציאות ניידת

ליישומים, תקשור ”לחץ _ id' ↔” התקן _ id' בצד של MMP/SDK.

כאשר אין זיהוי דטרמיניסטי (iOS privacy) - השתמש בהתאמה הסתברותית + כללי שרת, S2S נשאר ”האמת” לחיוב.

11) ניטור ו ־ SLAs

מדדים:

postbacks מוצלח/שגוי (%/min), p95 latency, פרופורציה של מגשים מחדש, פרופורציה של שכפולים.
אי התאמת אירוע בין הצדדים (מפעיל נגד גשש) ביום.
עיכוב משלוח (בליעה) ו ”כשלונות” לפי שעה.

SLA (דוגמה):

זמינות קליטה לאחר הגב 99. 5 %/חודש
העיכוב הממוצע לפני הכתיבה ל-DWH היה 60 שניות; תגובה p95 API רשומה 500 מ "מ.
Desynchronization of data> 3% _ פיוס חובה של יומנים גולמיים בתוך 5 ימי עבודה.

12) רשימות בדיקה

12. 1. בדיקת טכנולוגיה לפני השיגור

[ ] Redirector עם דור click_id ויומנים.

[ ] Postback endpoint: TLS, HMAC, JWT, IP Low-List, idempotency.

[ ] תוכניות מטען וסדר שדה קנוני מתועדים.

[ ] תורים + DLQs, מגשים, התראות שגיאה/עיכוב.

[ ] זמן UTC, מטבע ISO, FTD/Refund/Chargback כללים.

[ ] רץ בארגז חול עם תיקון יומני ייחוס.

12. 2. בדיקת הפעלה (כל שבוע)

[ פיוס ] ”מפעיל ↔ גשש” לפי כמות האירועים והכמויות.

[ ניתוח ] של שכפולים ומאורעות ”אבודים”; ביקורת של מגשים מחדש.

[ ] בודק מפתחות/אסימונים, תקופות חיים, וסבב.

[ ] לראות תקריות ולהתאים כללים.

13) טעויות תכופות וכיצד להימנע מהן

1. No idempotency # FTD משוכפל ב ־ Retrays. # Enter 'event _ id' and store ”נראה”.

2. אזורי זמן שונים * ”צף” D0/D1. # תמיד UTC ביומן האירוע.

3. סכומי מחרוזת/פסיק = שגיאות פירוק. = מספרי מעבר עם מחזור ומטבע ISO.

4. החתימה על ”גלם” JSON # נשברת מסדר המפתחות. # Do canonization.

5. אין DLQ/Retrays = אובדן אירועים במיקרוסובבים.

6. אימות חלש = postbacks מזויף. = HMAC + JWT + mTLS/IP list.

7. מחסור בכללי FTD * סכסוכי חיוב. = תקן את ההגדרות בחוזה.

14) בקשות דוגמיות ותגובות

14. 1. POST/postback (מפעיל ac tracker)


POST/postback HTTP/1. 1
תוכן-סוג: יישום/json
אישור: Bearer eyJbGCiOI...
חתימת X: Sh256 = Ab12...

"אירוע": "הפקדה _ הצלחה", "אירוע _ id':" dep _ 9aa "," click_id":"clk_123,""account_id":"u_456, "" סכום ": 100. 00, ”מטבע ”: ”USD”,” is _ ftd”: נכון, ”ts_event":"2025-10-21T15:12:31Z”

תשובה:


200 אישור
סטטוס: ”בסדר”, ”אידמפוטנט”:

התחדש עם אותו "אירוע _ id':


200 אישור
סטטוס: ”בסדר”, ”אידמפוטנט”: נכון

14. 2. שגיאת חתימה


403 אסורים
”שגיאה ”: ”חתימה _ לא תקפה”, ”רמז ”:” לבדוק סדר קנוני”

15) אירועים וניתוחים

תסמין: למפעיל יש על-חלל = 120, יש לך 117.

תכנית:

1. פיוס של טווח זמן (UTC) ומטבעות.

2. פורק יומנים גולמיים על ידי ”event _ id'/” click _ id'.

3. חיפוש אחר אסימון/אידמפוטנטיות דחויה עקב חתימה/TTL.

4. משלוח נוסף של אירועים ”תקועים” מ-DLQ, פעולות פיוס.

16) 30-60-90 תוכנית יישום

0-30 ימים - MVP מעגל

כור הפעלה עם "קליק _ id' ורישומים.

יישום קבלת הדואר: HMAC, JWT, idempotency, תורים, DLQ, התראות.

הרם את ארגז החול, הפעל את התסריט של reg/FTD עם כמויות בדיקה.

תיעוד שרטוטי שדה וקאנוניזציה.

31-60 ימים - איכות וסולם

כלל אירועים כספיים וחשבונאות מטבע כפול (txn & report).

הגדרת ניטור של latency p95, סתירות ומגשים מחדש.

חתום על נוהלי SLAs/תקרית; להוסיף צ 'רקבק/החזר אירועים.

ב-BI, אוספים תצוגות: FTD, Payback, D7/D30 ARPU.

61-90 ימים - קיימות וביקורת חשבונות

הזן סבב של סודות/תעודות, בדיקות עמידות לקלקול.

בצע בדיקות עומס ו ”תרגילי חירום” (תור טיפה/DB).

הגדר באופן פורמלי ספרי השמעת פיוס וביקורת רבעונית של תוכניות/כללים של FTD.

17) השורה התחתונה

מעקב S2S הוא ”עמוד השדרה” של ייחוס כנה וחיוב: click_id כמפתח העיקרי, דואר אלקטרוני מוגן, אידמפוטנטיות, מגשים מחדש והיגיינת זמן/מטבע קפדנית. הוסף לחוקי התוקף השקופים של FTD, אירועי צ 'ארג' בק וניטור בוגר - ותקבל מערכת אמינה שבה כל המרה מאושרת על ידי השרת ומתכנסת בדוחות לסנט אחד.