პარტნიორობის სქემები და ვერტიკალები

1) ტერმინები და როლები

ვერტიკალური არის ინდუსტრიის სეგმენტი ან/და ღირებულების ჯაჭვი (მაგალითად: Fintech/გადახდა, მარკეტინგი/აფილიტები, შინაარსი/პროვაიდერები, იდენტიფიკაცია/KUS, ანტიფროდი, ლოჯისტიკა/ფულფილმი, მხარდაჭერა BPO).

• Referral/Influencer/Affiliate - უზრუნველყოფს ტრაფიკს/ლიდებს (CPA/RevShare).
• Reseller/Distributor - იყიდება და ემსახურება ადგილობრივ ბაზრებზე.
• OEM/Embedded/White-label - შეინარჩუნეთ ფუნქციონირება, წარმოიქმნება მათი ბრენდის ქვეშ.
• ტექნოლოგია/ISV/SI - პროდუქტს ავსებს მოდულებითა და ინტეგრაციით.
• Data/Compliance - KYC/AML/მორიელი/გადახდა/ანტიფროდი.
• შინაარსი/მედია/Streaming - ლიცენზიები, შინაარსის ფიდები, სარეკლამო აქტივები.

2) ფასეულობების რუკა და პარტნიორების ჯაჭვი

პირველი, ჩვენ აღვნიშნავთ ღირებულების ნაკადის რუქას: მოთხოვნის წყაროდან პროდუქტამდე - მონეტიზაციამდე და პოსტ-სეილის მომსახურებამდე.

mermaid flowchart LR
A [Traffic Source/Partner 1] -->    Lead/Event    In [Platform/Product]
B -->    Deal/Transaction    C [Payment/Antifraud/ACC]
B -->    Content/API    D [Content Provider]
B -->    Webhooks/Events    E [PRM/CRM/Analytics]
B -->    SLA/Support    F [Reseller/Support-BPO]

თითოეული ისრისთვის ჩვენ განვსაზღვრავთ: მონაცემთა კონტრაქტი, მეტრიკა (SLI/SLO), წვდომა და საიდუმლოებები, კონფიდენციალურობის წესები, კომერციული მოდელი.

3) თანამშრომლობისა და კომერციის მოდელები

3. 1 თანამშრომლობის ფორმატები

Referral/Affiliate: Effssmils, postbacks, cuks/სერვერის ატრიბუტი.
Reseller/Distributor: კვოტები, ფასები, ადგილობრივი კანონის შესაბამისობა, L1/L2 მხარდაჭერა.
OEM/Embedded/White-label: SDK პაკეტები, თეთრი-label UI, release train და API თავსებადობა.
ბაზარი/App Store: ინტეგრაციის კატალოგი, ბილინგი პლატფორმის, შურისძიებისა და უსაფრთხოების საშუალებით.

3. 2 კომერციული მოდელები

CPA (Cost per Action): დადასტურებული მოქმედების ფიქსი.
RevShare: ზღვარი/შემოსავლის%; მნიშვნელოვანია გაანგარიშების ბაზის და ატრიბუტის ფანჯრის დაფიქსირება.
Hybrid: CPA + RevShare.
MDF/Co-op: ერთობლივი მარკეტინგის ფონდი KPI- ს მისაღწევად.
Minimum Guarantees: მინიმალური გადახდა/კვოტა.

საკვანძო დათქმები: ანტი-ფროდი, მიზნობრივი კლასები (გეო/არხები), „პრეტენზიების“ პერიოდი, აუდიტის უფლება, პასუხისმგებლობის შეზღუდვები.

4) მონაცემთა ხელშეკრულებები და ატრიბუტები

4. 1 ატრიბუტი

ფანჯარა (მაგალითად, '7/30' დღე), მოდელები (last-click, data-driven), არხების პრიორიტეტი, სერვერის პოსტბეკი.
წყაროები: UTM/ref პარამეტრები, c2s მოვლენები, ხელმოწერილი ვებჰუკები, dedupe 'event _ id'.
პირობები: „qualified“ სტატუსი, დედაპლატი, გაუქმება/რეფენდი, „cool-off“ პერიოდი.

4. 2 მონაცემთა ხელშეკრულება

სქემები (JSON Schema/Avro), სავალდებულო ველები/PII, იურიდიული ბაზა, TTL/retenshen, საგნის უფლებები (ამოღება/გამოსწორება), ლოკალიზაცია (რეგიონი).
ინტეგრაციის SLA: მიწოდებული მოვლენების წილი - X წუთი, ბრძანება/იდემპოტენტობა, გამეორების ფანჯრები.

json
{
"event_id": "uuid",
"occurred_at_utc": "2025-10-31T12:01:02Z",
"type": "partner. conversion. v1",
"partner_id": "aff_123",
"attributes": {
"click_id": "abc",
"amount": 49. 90,
"currency": "EUR",
"status": "qualified"
},
"signature": "base64",
"version": 1
}

5) ინტეგრაციის ნიმუშები

REST/gRPC ონლაინ გაცვლისთვის (კვოტები/ლიმიტები, რეპროდუქციული პოლიტიკა, იდემპოტენტობა).
Webhooks/Eventing - ხელმოწერილი მოვლენები, ექსპონენციალური შეფერხების განმეორება, დაკავებული ხაზები „ნელი“ პარტნიორებისთვის.
Batch/SFTP/Blob - მოხსენებები, თაღები, ჩანაწერები.
SDK/Embeds არის მინიმალური ხახუნის კავშირი, ვერსიის პოლიტიკა, feature-flags.
Outbox/Inbox - გარანტირებული მიწოდება, დედაპლატი, აუდიტი.
Consent/Privacy API - თანხმობის პროპაგანდა ჯაჭვში.

6) კასკადის SLA/OLA და ესკალაცია

SLA გარე: წვდომა, p99, მოვლენების წილი ფანჯარაში, ატრიბუტის სიზუსტე.
OLA შიდა: PRM ოპერაციები, გადამოწმება, საპორტო საპასუხო პასუხი, თიკეტების დახურვა.
კასკადი: გარეგანი დარღვევა - შინაგანი მოქმედებების გამომწვევი, სესხები/ჯარიმები (ხელშეკრულებით), სტატუსი PRM- ში.
ესკალაცია: L1 პარტნიორი, L2 პლატფორმა, L3 ინფრასტრუქტურის გამყიდველი; ფიქსირებული პასუხის ფანჯრები.

7) PRM: ოპერაციული მოდელი და პროცესები

1. Sourcing/Screening: კითხვარი, ICC/სანქციები, რეპუტაცია, ეს შესაძლებლობები.

2. Onboarding: ხელშეკრულებები, გასაღებები/API, ქვიშის ყუთები, ინტეგრაციის შემოწმების ფურცლები, ტესტის შემთხვევები.

3. Enablement: ტრენინგი, შემოქმედებითი თემების ბიბლიოთეკა/UTM, შინაარსის ჰაიდები/ბრენდი.

4. რუნი: მოხსენებები, MDF, ერთობლივი OKR, SLA სტატუსები, ალერტები.

5. მიმოხილვა და გროვა: QBR (quarterly business მიმოხილვა), co-roadmap, cross-sell.

6. Exit/Change: შეწყვეტა, მონაცემების ექსპორტი, გასაღებების მიმოხილვა, პოსტ-შურისძიება.

PRM არტეფაქტები: პარტნიორის პასპორტი, ნებართვის მატრიცა, თანხმოვნების რეესტრი, რისკის რეესტრი, playbooks, API კოპირება, ვერსიის თავსებადობის სტატუსი.

8) ვერტიკალები: მახასიათებლები და ინვარიანტები

მარკეტინგი/Affiliates: ბრძოლა frode (ბოტები, cookie-stuffing), მკაცრი ატრიბუტი, შინაარსის სახელმძღვანელო და ბრენდის უსაფრთხოება.
გადახდები/Fintech: მონაცემთა სუვერენიტეტი, 3-D Secure/PSD მსგავსი მოთხოვნები, KMS/დაშიფვრა, უკუკავშირი რისკზე.
KUS/ანტიფროდი: მგრძნობიარე PD, DPA, TTL, საგნის უფლებები, მატჩის ხარისხი.
შინაარსი/მედია: ლიცენზირება, DRM/წყლის ნიშნები, მეტამონაცემები, გამოყენების ანგარიშები.
მხარდაჭერა VRO/Resellers: სცენარები L1/L2, სკრიპტები, სასწავლო კურსები, ხარისხის კონტროლი.

ზოგადი ინვარიანტები: PoLP, დაშიფვრა, აუდიტი, მოვლენების imempotence, აშკარა ატრიბუტისა და გაანგარიშების ფანჯრები.

9) არხის კონფლიქტის მენეჯმენტი

პრიორიტეტული წესები: ვინ ფლობს კლიენტს კვეთაზე (პირველადი რეგისტრაცია, აქტივობა, ჩეკი).
დაცვა/ექსკლუზიურობა: გეო/სეგმენტის/კამპანიის ექსკლუზიური - KPI- ით და ვადით.
„Last-touch vs dat- driven“: დაფიქსირდეს მოდელი და მისი გადასინჯვა.
არბიტრაჟი: ანალიზის პროცესი, პრეტენზიის ფანჯრები, მტკიცებულებათა ბაზა (ლოგოები, ხელმოწერები, ტრეისი-ID).

10) რისკები და კონტროლი

იურიდიული/ბრენდირებული: აკრძალული კრეატიულობა, ადგილობრივი კანონის/რეკლამის შეუსაბამობა.
ფინანსური: არასწორი ატრიბუტი, „ნაცრისფერი“ ოპტიმიზაცია CPA- სთვის, chargeback რისკი.
ტექნიკური: გასაღების გაჟონვა/PII, ვებჰუკების ნაკლებობა, სქემების დრიფტი.
ოპერაციული: დამოკიდებულება ერთ დიდ პარტნიორზე, გათვლებით „შავი ყუთები“.

კონტროლირებადი: პოლიტიკა, როგორც კოდი (OPA/Kyverno), საიდუმლო სკანერები, ლიმიტები, honey-tokens, „ორმაგი“ გაანგარიშება (თქვენი და პარტნიორის) + რეკონსტრუქცია.

11) მეტრიკი და KPI

მოთხოვნის წყარო: CAC, LTV/CAC, ARPU/ARPPU, CR, Churn by partner.
ატრიბუტის ხარისხი: „qualified“ წილი, დედების წილი, ანგარიშების შეუსაბამობა (<).
ოპერაციული: ონბორდის დრო, პარტნიორების წილი მიმდინარე კლავიშებით/ვერსიებით SDK, SLO ღონისძიებების მიწოდებით.
რისკი/შესაბამისობა: არსებული DPA, SLA pass-rate პარტნიორების%, ინციდენტები/მილიონი მოვლენა.
ზრდა: შემოსავლის წილი ახალი ვერტიკალებიდან, ჯვარედინი სელიდან, აქტიური ინტეგრაციების რაოდენობა.

12) შაბლონები და მაგალითები

12. 1 პარტნიორის პასპორტი (YAML)

yaml partner_id: "aff-123"
name: "Acme Media"
vertical: "Marketing/Affiliates"
regions: ["EU","TR","LATAM"]
contracts:
msa: "2025-01-10"
dpa: "2025-01-10"
commercials:
model: "Hybrid"
cpa: 50 revshare: "20% of net"
attribution:
window_days: 30 model: "last_click"
postback: "https://acme. example/postback"
data_contract:
event_schema: "conversion. v1"
pii: false retention: "365d"
delivery_sla: "95% <= 5m"
security:
webhooks: { signature: "HMAC-SHA256", replay: 300 }
scopes: ["conversions:read"]
status:
sandbox: "passed"
production: "active"
owners:
biz: "partner-team"
tech: "integrations-team"

12. 2 PRM კარიბჭის პოლიტიკა (ფსევდო-რეგო)

rego package prm. gates deny["No DPA"] { input. partner. dpa == null }
deny["Weak signature"] { input. partner. webhooks. signature not in {"HMAC-SHA256","Ed25519"} }
deny["Missing attribution window"] { not input. partner. attribution. window_days }

12. 3 რეკონსტრუქცია (ფსევდო-SQL)

sql
SELECT a. event_id
FROM partner_report a
LEFT JOIN internal_events b ON a. event_id = b. event_id
WHERE b. event_id IS NULL AND a. occurred_at >= now() - interval '30 days';

13) ანტი შაბლონები

„პირველ რიგში, ჩვენ მოვაწერთ ხელს - მოგვიანებით შევხვდებით ინტეგრაციას“ - მკვდარი პარტნიორები და დავალიანებები.
ატრიბუტი მხოლოდ მუწუკებით და სერვერის სიგნალების გარეშე არის სპორები და თაღლითობა.
საიდუმლოებები და ვებჰუკები ხელმოწერის გარეშე/ანტი-replay - გაჟონვა და ჩანაცვლება.
ერთი „სუპერ პარტნიორი“> ტრაფიკის 50% კონცენტრაციის რისკს წარმოადგენს.
ჩანაწერების და აუდიტის არარსებობა გამოთვლებში ქრონიკული განსხვავებებია.
არაკოორდინირებული SLA/OLA არის პასუხისმგებლობის „ნაცრისფერი ზონები“.
ადგილობრივი შეზღუდვების უგულებელყოფა შინაარსის/რეკლამირების შესახებ, დაბლოკვა/ჯარიმები.

14) არქიტექტორის ჩეკის სია

1. თითოეული ვერტიკალზე აგებულია მონაცემთა/ფულის ღირებულებისა და ისრების რუკა?
2. თითოეული პარტნიორისთვის არის პასპორტი: ხელშეკრულებები, სქემები, SLO, გასაღებები, რეგიონები, მეპატრონე?
3. ატრიბუტი: განსაზღვრულია ფანჯარა, მოდელი, სერვერის პოსტბეკები, დედაპაპი და რეკონსტრუქცია?
4. ინტეგრაცია: ხელმოწერა, რეტრაები, იდემპოტენტობა, შეზღუდვები - ხორციელდება?
5. პოლიტიკოსები, როგორიცაა კოდი: DPA/SLA/ხელმოწერები/retenshen - კარიბჭეები CI/CD- ში?
6. PRM პროცესები: ონბორდი, ტრენინგი, QBR, MDF, exit გეგმა - აღწერილი და შესრულებული?
7. კასკადის SLA/OLA და ესკალაცია - ჩაწერილია და ტესტირდება?
8. მეტრიკა: CAC/LTV/CVR/C- შეუსაბამობები, SLO მიწოდება - დაშბორდებზე?
9. რისკის კონტროლი: ანტი-ფროიდი, კონცენტრაციის ლიმიტები, honey-tokens, საკვანძო მიმოხილვის გეგმა?
10. API/SDK/მოვლენების ვერსია და „თავსებადობის ფანჯრები“ - გამოშვების კალენდარში?

დასკვნა

პარტნიორობის სქემები არის ურთიერთობების, მონაცემებისა და სტიმულირების არქიტექტურა. როდესაც გაქვთ ღირებულების რუკა, ფორმალური მონაცემთა კონტრაქტები, გამჭვირვალე ატრიბუტი, კასკადის SLA და კონტროლირებადი ინტეგრაცია, ეკოსისტემა პროგნოზირებადი ხდება: პარტნიორები ხედავენ სარგებელს, მომხმარებლები - ხარისხს, ხოლო პლატფორმა - სტაბილურ ზრდას. ააშენეთ PRM, როგორც პროდუქტი, ავტომატიზაცია მოახდინეთ პოლიტიკაზე და გაზომეთ ეფექტები - და თქვენი ქსელი მასშტაბური იქნება ქაოსის გარეშე.