Postback S2S

Integracja GG3 z systemami partnerów za pomocą Postback S2S (Server-to-Server) ma na celu umożliwienie efektywnego śledzenia i rejestrowania działań użytkowników GG3 na platformach partnerów.

Czym jest S2S?

Komunikacja s2s (server-to-server) to proces wymiany danych pomiędzy dwoma serwerami bez bezpośredniego udziału użytkowników. Jest ona szeroko stosowana w różnych aplikacjach internetowych, mobilnych. Procesy mogą być wykonywane automatycznie bez konieczności interwencji użytkowników, co zwiększa efektywność i zmniejsza ryzyko błędów ludzkich.

Jaki ma cel integracja S2S?

W celu uzyskiwania informacji wymaganych do wykonywania questów, które oparte są o aplikację partnera konieczne jest wykonanie integracji między GG3, a partnerem. Integracja jest konieczna, dla poprawnego rejestrowania aktywności wykonywanych przez naszych użytkowników na platformie partnera. Wynika to z faktu, że tylko aplikacja partnera wie, co użytkownik na niej wykonuje.

Jak działa integracja S2S?

Link trackujący pozwala na śledzenie interakcji użytkowników z zasobami online, takimi jak reklamy czy strony partnerów. Poniżej znajdziesz instrukcję dotyczącą tworzenia linku trackującego, w którym przekazywane są parametry user_id oraz click_id.

Struktura Linku Trackującego:

1. Podstawowy URL

Podstawowy URL to adres strony docelowej, na którą ma zostać przekierowany użytkownik. Może to być adres witryny, strony produktu, strony rejestracji itp.

2. Parametry Zapytania

Parametry zapytania to dodatkowe informacje dołączane do URL, które pozwalają na śledzenie i identyfikację konkretnych interakcji użytkowników. W tym przypadku są to user_id oraz click_id.

Przykład Konstrukcji Linku Trackującego

Załóżmy, że podstawowy URL to:

<https://www.example.com/landing-page>

Aby dołączyć parametry user_id oraz click_id, używamy znaku zapytania ? do oddzielenia podstawowego URL od parametrów zapytania, a następnie dodajemy parametry w formacie klucz=wartość. Kolejne parametry oddzielamy znakiem &.

Przykładowy Link Trackujący

<https://www.example.com/landing-page?user_id=12345&click_id=67890>

Elementy Linku Trackującego

1. Podstawowy URL: https://www.example.com/landing-page

2. Znak zapytania: ? - oddziela podstawowy URL od parametrów zapytania. WAŻNE: może być tylko 1. Pozostałe parametry łączymy &

3. Parametry zapytania:

   • user_id=12345 - identyfikator użytkownika, tutaj 12345.

   • click_id=67890 - identyfikator kliknięcia, tutaj 67890.

Działanie

1. Kliknięcie w Link: Kiedy użytkownik kliknie w link trackujący, przeglądarka przekierowuje go na stronę docelową https://www.example.com/landing-page z dołączonymi parametrami user_id i click_id.

2. Przetwarzanie Parametrów: Strona docelowa lub serwer, który ją obsługuje, odbiera URL z parametrami i może je przetworzyć. Na przykład, może zapisać informacje o użytkowniku i kliknięciu w bazie danych w celu śledzenia konwersji i analizy danych.

Zalety

• Śledzenie Użytkowników: Parametr user_id pozwala na identyfikację konkretnego użytkownika.

• Śledzenie Kliknięć: Parametr click_id pozwala na śledzenie i analizę poszczególnych kliknięć, co jest przydatne w analizie efektywności kampanii reklamowych.

• Personalizacja: Na podstawie tych parametrów można dostosować treść strony docelowej do konkretnego użytkownika.

Podsumowanie

Link trackujący z parametrami user_id i click_id to prosty, ale potężny mechanizm umożliwiający dokładne śledzenie interakcji użytkowników z zasobami online. Pozwala to na lepszą analizę, raportowanie i optymalizację działań marketingowych oraz kampanii reklamowych.

Konstrukcja Postbacku s2s

Postback s2s (server-to-server) to mechanizm umożliwiający przesyłanie danych pomiędzy serwerami po wystąpieniu określonego zdarzenia, takiego jak dokonanie zakupu, rejestracja czy inne działania użytkownika. Partner wysyła impuls do usługi GG3 w przypadku wystąpienia umówionej akcji. W przypadku postbacku, parametry takie jak user_id, click_id, currency, oraz amount_decimal są przesyłane w celu śledzenia i analizy tych zdarzeń. Każde przesłane zdarzenie musi posiadać unikatowy identyfikator transakcjitransaction_id . Dodatkowo, dla kampanii opartych na wielu zdarzeniach (multi event), mogą być przekazywane event_id oraz event_name.

Struktura Postbacku s2s

1. Podstawowy URL

Podstawowy URL to adres endpointu serwera odbierającego dane postbacku. Jest to punkt końcowy, do którego serwer wysyłający postback (serwer A) przesyła dane do serwera odbierającego (serwer B).

2. Parametry Zapytania

Parametry zapytania to dane, które są przekazywane w URL postbacku. W przypadku naszego scenariusza, są to user_id, click_id, currency, amount_decimal, transaction_id a opcjonalnie event_id oraz event_name.

Przykład Konstrukcji Postbacku s2s

Załóżmy, że podstawowy URL endpointu to:

<https://www.example.com/postback>

Aby dołączyć parametry user_id, click_id, currency, amount_decimal, transaction_id, a opcjonalnie event_id oraz event_name, używamy znaku zapytania ? do oddzielenia podstawowego URL od parametrów zapytania, a następnie dodajemy parametry w formacie klucz=wartość. Kolejne parametry oddzielamy znakiem &.

Przykładowy Postback s2s

<https://www.example.com/postback?user_id=12345&click_id=67890&&transaction_id=123123123&currency=USD&amount_decimal=100.00>

Dla kampanii z wieloma zdarzeniami, z dodatkowymi parametrami:

<https://www.example.com/postback?user_id=12345&click_id=67890&currency=USD&amount=100.00&event_id=001&event_name=purchase>

Elementy Postbacku s2s

1. Podstawowy URL: https://www.example.com/postback

2. Znak zapytania: ? - oddziela podstawowy URL od parametrów zapytania.

3. Parametry zapytania:

   • user_id=12345 - identyfikator użytkownika, tutaj 12345.

   • click_id=67890 - identyfikator kliknięcia, tutaj 67890.

   • currency=USD - waluta transakcji, tutaj USD (dolar amerykański).

   • amount_decimal=100.00 - kwota transakcji, tutaj 100.00.

   • transaction_id=123123123 - unikatowy identyfikator zdarzenia.

   • event_id=001 (opcjonalnie) - identyfikator zdarzenia, tutaj 001.

   • event_name=purchase (opcjonalnie) - nazwa zdarzenia, tutaj purchase (zakup).

Docelowe adresy URL przekazywane są partnerom po podjęciu współpracy.

Media Buying

Funkcjonalność wykorzystująca komunikację Postback S2S do tworzenia kampanii GG3 na stronach partnerów. Przykład: Partner umieszcza na swojej stronie zadania związane z platforma GG3 (kierując userów przez link_trakujący). Po kliknięciu w link, użytkownik przekierowywany jest na stronę GG3 w celu wykonania konkretnego zadania lub grupy zadań (np. rejestracji). Podczas rejestracji do usera przypisywany jest identyfikator usera (clickid, userid), dostarczony przez partnera w linku trakujacym. Partner dostaje informację zwrotną czy użytkownik spełnił określone zadania w platformie poprzez webhook url / S2S.

Przykładowy link trakujący

Link trakujący dostarczony jest partnerowi i dzięki temu użytkownik jest kierowany ze strony partnera w odpowiednie miejsce na platforme GG3.

Rodzaj przekazywanych danych (Tracking macros): user_id / click_id powinny być uzgodnione z partnerem.

Partner musi umieścić clickId/userId jako identyfikator w tym linku.

Przykład:

<https://gg3.xyz/quests/complete-50-quests?click_id={clickId}&provider={partner_name}>

Przykładowy postback URL/webhook URL

Adresy webhook url dostarcza partner, a my przypisujemy je do konkretnej akcji jaką user ma wykonać.

Informacje zwrotną otrzyma w webhookach (postbackach):

Przykład:

<https://webhook.site/2d80209a-b875-4744-a1a2-89fc79261307?userId={userId}&clickId={clickId}&event=rejestracja>

gdzie,

• userId - identyfikator użytkownika od partnera

• clickId - identyfikator kliknięcia

• event=[nazwa] - informacja o wykonaniu konkretnego działania na platformie GG3

Aktualnie dostępne typy eventów, które mogą być weryfikowane przez GG3 i przekazywane partnerom:

• Rejestracja (akceptowane są wszystkie możliwe opcje rejestracji dostępne w GG3)

• GGStrike - event oparty na ilości kliknięć GG-buttona

• Single MainQuest Complete - ukończenie określonego mainQuesta

• Multi MainQuest Complete - ukończenie grupy określonych mainQuestów (max 10). Informacja o spełnieniu wymagania przychodzi w momencie realizacji wszystkich mainQuestów.

Dane dotyczące użytkowników muszą być zbierane i przetwarzane przez partnera w dowolny sposób. Partner dostaje informacje o wykonaniu danego eventu przez określonego użytkownika.

W przypadku, gdy serwer partnera jest niedostepny, serwer nasz ponawia próbe wysłania informacji do partnera 5 razy, za każdym razem zwiększając czas przerwy o wielokrotność próby przemnożonej przez czas startowy.