Marżowość - utrzymywanie marży per klient w ROAS + boostowanie

Biznesowo

Cele

1. Utrzymanie marży per kampania x ssp na zadanym poziomie na koniec miesiąca, z uwzględnieniem tego, że w trakcie miesiąca marża może się wahać. Marża ta jest zdefiniowana na podstawie wydatków w danym miesiącu i przychodów w danym miesiącu, a nie na podstawie przychodów atrybuowanych do wydatków w danym miesiącu.
2. Gdy klient zwiększa stawkę, na kampanię będziemy mogli wydać więcej pieniędzy (zboostować ją), ponieważ dostaliśmy nieplanowane przychody z konwersji z nową stawką, ale atrybuowanych do aukcji wycenianych ze starą stawką.

Założenia

1. Konwersja będzie rozliczana ze stawką obowiązującą w chwili skonwertowania, a nie, jak do tej pory, ze stawką obowiązującą w chwili trwania aukcji.
2. Bidder nie wie jaka stawka będzie obowiązywać w przyszłości (wie jedynie o stawce obowiązującej w momencie aukcji), więc bidder wycenia wartość oczekiwaną przychodu z aukcji przy założeniu, że stawka nie zmieni się w przyszłości.
3. Do optymalizacji wliczamy ruch retargetingowy (w tym retargeting po IP) oraz ruch prospectingowy kampanii ROAS. Marża ma być na wybranym poziomie dla tych źródeł branych łącznie.
4. Przecięcia w jakich ma być ustawiana marża to (klient x medium x ssp)
5. Nie mamy założeń co do wielkości oraz długości trwania boostu spowodowanego zmianą stawki.
6. Źródłem prawdy dla przychodów jest tabela uber_all, źródłem prawdy dla wydatków jest tabela bidData. Jeśli mechanizm zasilający te tabele ulegnie awarii to kontrolowana marża może być niepoprawna i wymagana będzie ręczna interwencja. Ręczne interwencja mogłaby być wprowadzona np. poprzez:
   1. możliwość wykluczenia dni, z których statystyki są niepoprawne
   2. ręczne wprowadzanie wydatków/przychodów w poszczególne dni
7. Przychody brane do liczenia marży to przychody emisyjne (tj. przychody po naszych statystykach).
8. Na wydatki organizacji składają się:
   1. wydatki będące sumą biddów z wygranych aukcji
   2. prowizje od wydatków z pkt 1., płacone na koniec miesiąca (dla pośrednika / agencji) Marżę liczoną z 1. nazwijmy marżą emisyjną, natomiast marżę liczoną na podstawie 1. + 2. nazwijmy marżą rzeczywistą. Utrzymywanie docelowej marży odbywa się dla marży rzeczywistej, czyli z uwzględnieniem prowizji płaconych na koniec miesiąca. Przykładem jest wpartner, tam mamy marżę emisyjną ustawioną +15%, ale marża rzeczywista wynosi 0%.
9. Obecnie liczone wydatki emisyjne nie uwzględniają sytuacji, w których płacimy za niewyrenderowaną reklamą. Takie sytuacje mają miejsce na sspbc na platformach innych niż wplatform oraz prebidserver. Marża, którą będziemy kontrolować powinna uwzględniać te sytuacje.

Dodatkowe założenia

1. Testy rozwiązania zaczniemy od kilku kampanii, które:
   1. Są największe
   2. Rozliczają się w atrybucji last-click
   3. Są w display

Technicznie

Wymagane zmiany:

1. Kontroler (nowy mechanizm liczący poprawkę)
   1. Implementacja powinna wyglądać tak jak implementacja kontrolera w CPA - tworzymy obraz dockera, który jest odpalany jako feature zdockeryzowany hopping w Feature Store. Bidder otrzymuje wartość $\tau$, która jest uwzględniana w wycenie. Wartość $\tau$ powinna być logowana w nowej kolumnie w bidData.
2. Bidder
   1. Uwzględnienie w wycenie poprawki wyliczoną przez kontroler. Kontroler powinien być łatwo wyłączalny (growthbook)
   2. Zmiana w sposobie uwzględniania prowizji pośrednika - trzeba dodać dodatkową kolumnę w bidData z prowizją pobieraną na koniec miesiąca. Rzeczywiste wydatki biddera będą wtedy wynosić myPrice + prowizja. Będzie to wymagać dodatkowe GB do ustalania prowizji.
3. Metrics
   1. W metricsie powinno powstać rozróżnienie pomiędzy wydatkami emisyjnymi (marżą emisyjną) a wydatkami rzeczywistymi (marżą rzeczywistą).
4. Uber_all:
   1. w wpclid powinniśmy mieć dostęp do stawki z chwili konwersji, nie z chwili bidowania
5. Utworzenie panelu do ustawiania docelowej marży rzeczywistej.
6. Modele:
   1. Model CTR powinien liczyć wydatki i marżę z uwzględnieniem, że na niektórych platformach płacimy za event iFrameCreated, a nie za delivery.
7. Optymalizacja bidData. Obecna bidData nie pozwala analizować wyników testów A/B dłużej niż z kilku dni, a w przypadku zmian, które szykujemy będziemy musieli prowadzić test dłużej. Dlatego proponuję:
   1. zmigrować dane z bidData do nowej tabeli z poprawnie założonymi indeksami, co pozwoli znacząco szybciej odpytywać bazę
   2. założyć tabelę agregującą dane z bidData
8. Monitoring:
   1. Na marżę kontrolowaną przez kontroler składa się marża, która może być liczona w różnych przecięciach, np. retargeting/prospecting, display/applications, roas-po-ip/roas-zwykły, przeglądarka, mobile/desktop itp. Powinniśmy stworzyć mechanizm, który pozwoli analitykowi łatwo przejrzeć czy w którymś z tych przecięć marża odbiega od założonej. W dodatku taki monitoring powinien nas informować o takiej sytuacji.

Co zostaje bez zmian:

1. Sposób wyceny modeli:
   1. Modele estymują wartość oczekiwaną przychodu ze stawką obowiązującą w chwili aukcji.
   2. Modele oceniane są (i trenowane) na danych, w których atrybuujemy konwersję do konkretnego klika oraz klik do konkretnej aukcji.
   3. Kalibracja online modeli (oraz inne narzędzia online, np. bayesian) koryguje wyceny na podstawie danych spływających z produkcji, ale w swojej korekcji nie próbuje nadrobić niepoprawnych wycen z przeszłości, tj. wprowadza korektę taką, która od teraz spowoduje lepsze wyceny

Kontroler

Nowy mechanizm, który musimy napisać od zera. Wprowadzamy mechanizm kontrolujący wydatki i przychody pojedynczej kampanii, patrzący na wydatki i przychody od początku miesiąca, niezależnie do jakiej konkretnie aukcji została zatrybuowana konwersja.

Wejście:

1. $S_{k,\sigma ,d}$ - wydatki rzeczywiste kampanii $k$ dla ssp $\sigma$ na moment czasu $d$
2. $I_{k,\sigma ,d}$ - przychód kampanii $k$ dla ssp $\sigma$; przychód liczony jest ze wszystkich konwersji w danym miesiącu na moment czasu $d$
3. $d$ - czas do końca okresu optymalizacji (tj. do końca miesiąca)
4. ${\Omega }_{k,\sigma }$ - oczekiwana marża

Wyjście:

1. ${\tau }_{k,\sigma }$ - wartość przez jaką powinniśmy pomnożyć wyliczony wcześniej (przez modele) oczekiwany przychód z aukcji $b$ dla kampanii $k$ oraz ssp $\sigma$. Tzn. odpowiedzią biddera będzie wartość $b\cdot {\tau }_{k,\sigma }$. Uwaga: $0<{\tau }_{\text{min}}\le {\tau }_{k,\sigma }\le {\tau }_{\text{max}}$ dla pewnych ustalonych ${\tau }_{\text{min}}$ oraz ${\tau }_{\text{max}}$

Zadanie: Ustalić takie ${\tau }_{k,\sigma }$ aby zminimalizować $|\frac{I_{k,\sigma ,0}-S_{k,\sigma ,0}}{I_{k,\sigma ,0}}-{\Omega }_{k,\sigma }|$ , czyli zminimalizować odchylenie marży faktycznej od marży oczekiwanej na koniec miesiąca.

Uzasadnienie podejścia

Kalibracja modeli online poprawia wyceny zawsze od obecnej chwili, nie korygując dotychczasowego błędu. Nowy kontroler będzie korygował dotychczasowy błąd, próbując w przyszłych aukcjach nadrobić dotychczasowe manko lub nadwyżkę. Stąd w mojej ocenie oba mechanizmy nie będą sobie wzajemnie przeszkadzać.

Jak będzie wyglądać wycena

Wycena kampanii $k$ w aukcji $a$:

$$\begin{array}{rl}{b}_a& =\min (\mathbb{E}[{\text{income}}_a|{\text{win}}_a]\cdot (1-{\text{s}}_p)\cdot {\tau }_{k,\sigma },C)\\ & =\min (\left[\mathbb{P}[{\text{click}}_a|{\text{win}}_a]\cdot \mathbb{P}[{\text{purchase}}_a|{\text{click}}_a]\cdot \mathbb{E}[{\text{BV}}_a|{\text{purchase}}_a]\cdot {\text{fee}}_k\cdot M_{k,\sigma ,...}^{\ast }\right]\cdot (1-{\text{s}}_p)\cdot {\tau }_{k,\sigma },C)\end{array}$$

gdzie

$$\begin{array}{rl}\mathbb{P}[{\text{click}}_a|{\text{win}}_a]& ={\delta }_{\text{CTR}}(\hat{\mathbb{P}}[{\text{click}}_a|{\text{win}}_a])\\ \mathbb{P}[{\text{purchase}}_a|{\text{click}}_a]& ={\delta }_{\text{CVR}}(\hat{\mathbb{P}}[{\text{purchase}}_a|{\text{click}}_a]\cdot M_{\text{preCVR}})\cdot M_{\text{postCVR}}\end{array}$$

Zmienne losowe:

• ${\text{win}}_a$ - zmienna binarna informująca o tym, czy wygraliśmy aukcję $a$; wygranie aukcji jest równoznaczne z zapłatą kwoty, którą wcześniej licytowaliśmy aukcję $a$
• ${\text{income}}_a$ - zmienna ciągłe informująca o przychodach biddera z aukcji $a$
• ${\text{click}}_a$ - zmienna binarna informująca o tym, czy reklama z aukcji $a$ została kliknięta przynajmniej jeden raz
• ${\text{purchase}}_a$ - zmienna binarna informująca o tym, czy z aukcji $a$ powstała przynajmniej jedna konwersja zatrybuowana do naszego biddera
• ${\text{BV}}_a$ - zmienna ciągła informująca o tym jaka jest suma wartości zakupów konwersji powstałych z aukcji $a$

Pozostałe oznaczenia:

• $b_a$ - cena, którą bidder odpowiada w aukcji $a$
• $s_p$ - stawka prowizji od ceny bida, w przedziale $\left[0\%;100\%\right]$, jaką bidder musi zapłacić pośrednikom $p$ na koniec miesiąca
• $C$ - maksymalna cena, którą bidder może wysłać (capping)
• ${\text{fee}}_k$ - stawka kampanii $k$, w przedziale $\left[0\%;100\%\right]$
• ${\delta }_{\text{CTR}},{\delta }_{\text{CVR}}$ - kalibracja online odpowiednio modeli CTR i CVR
• $\hat{\mathbb{P}}$ - bezpośrednie wyjście z modelu
• $M_{\text{preCVR}}$ oraz $M_{\text{postCVR}}$ - mnożniki modelu CVR, ustawiane w GB cvr-score-coeffs
• $M^{\ast }$ - wszystkie pozostałe mnożniki zmieniające wycenę

Kolumny w bidData:

oznaczenie	kolumna
$b_a$	myPrice
${\text{fee}}_k$	billingModelValue

Dodatki

Dlaczego optymalizacja per godzina jest trudna?

Przykładem jest Sinsay, który jest sklepem z TOP 10 klientów. Sinsay ma 700 konwersji na miesiąc, czyli średnio 1 konwersja na godzinę. Przy takiej liczbie konwersji na godzinę nie jesteśmy w stanie zrobić optymalizacji na godzinę, bo dane będą za bardzo zaszumione.