Quartz 4

2023.10.18 fledge - plan analityczny

4 min read

Fledge

z perspektywy analityków

Zmiany

  1. Brak 3rd-party cookie:

    znamy zachowanie użytkownika tylko wewnątrz jednego, konkretnego sklepu (nie potrafimy połączyć id użytkownika pomiędzy dwoma sklepami).

  2. Anonimizacja:

    nie wiemy dokładnie jaki user kliknął w jaką reklamę.

Skutki

  • Skutki teoretyczne:

    • mniej wiemy o użytkowniku,
    • mniej cech.

  • Skutki praktyczne:

    • dla modelu CVR dla atrybucji post-click 10d Brier Skill Score spada z 0.042 do 0.030.

Zmiany w modelach

  1. algorytmy rekomendacyjne,
  2. BV,
  3. CTR,
  4. CVR,
  5. przypisywanie grup zainteresowań.

Algorytmy rekomendacyjne - zmiany

::: block

  • Architektura:

    • rekomendacje wysyłamy do przeglądarki w momencie gdy user jest na sklepie (ale to raczej nie jest duża zmiana).

  • Modelowanie:

    • jeden użytkownik żyje tylko w obrębie jednego sklepu,
    • każdy sklep żyje osobno (nie połączymy produktów z różnych sklepów) - będzie to problem głównie dla małych sklepów,
    • na początek można zostawić graf jak jest tylko będzie mniej krawędzi.

  • Uwaga:

    • produkty będą musiały być -anonimowe, tzn. produkt nie wyświetli się na reklamie dopóki nie zarekomendujemy go użytkownikom.

Algorytmy rekomendacyjne - plan

  • biddujemy tak jak teraz
  • (dopiero potem) przygotowujemy graf na usunięcie krawędzi (np. dodając sztuczne krawędzie między podobnymi produktami)

Model BV - zmiany

::: block

  • Modelowanie:

    • zakładam, że na początek podajemy średnią wartość koszyka (jak dotychczas) - wtedy brak zmian względem obecnego rozwiązania.

  • Architektura:

    • wysyłamy do przeglądarki średni BV w momencie gdy user jest na stronie.

Model CTR - zmiany

::: block

  • Architektura:
    • model wykonywany w przeglądarce,
    • ze względów wydajnościowych raczej nie wykonamy inferencji z sieci neuronowej, więc proponuję wytrenować model drzewowy (CatBoosta), a jeśli inferencja takiego modelu dalej będzie za wolna to przejść na modele liniowe
  • Modelowanie:
    • nie wiemy jaki użytkownik kliknął w jaką reklamę,
    • wiemy z jakiej grupy zainteresować pochodził klik

Model CTR - przepływ danych

Model CTR - łączenie danych

Model CTR - plan

::: block

  1. nadajemy IG jako userID + SN (na tę chwilę nie musimy zachowywać -anonimowości),
  2. trenujemy prosty model na cechach 1st-party, bez zachowania anonimowości,
  3. spinamy proces bidowania we fledge i logowania danych do CH,
  4. (dopiero teraz) zaczynamy nadawać IG w sposób -anonimowy,
  5. (dopiero teraz) trenujemy model z IGs i wykorzystujemy “sprytne” łączenie danych

Model CVR - raportowanie konwersji we Fledge

Note: doktoraty w jaki sposób łączyć dane z różnych raportów, debiasing, etc.

Model CVR - dane w pixlu

Notes: Dwie opcje:

  • albo user będzie miał tylko jedną grupę naraz
  • albo podczas przekliku będziemy przekazywać IG, ale musi to być -anonimowe

sprawdzić jak recency wpływa na wyniki

Model CVR - zmiany

::: block

  • Modelowanie:

    • tracimy informację o domenie, device (a są to istotne cechy dla modelu)
    • znamy tylko zachowanie usera na konkretnym sklepie,
    • mamy dokładnie informacje o konwersjach,
    • BSS na zbiorze testowym spada z 0.043 do 0.030.

  • Rozliczanie:

    • z klientami będziemy musieli rozliczać się w post-clicku

  • Architektura:

    • model wykonywany na naszych serwerach w momencie dodawania grupy zainteresowań, zapisuje się w przeglądarce jako liczba; uwaga: model per user!

Model CVR - plan na teraz

::: block

  1. robimy model oparty tylko na danych z uber_all, na naszych użytkownikach, w atrybucji post-click; dla modelu to cechy z momentu gdy nadajemy grupę zainteresowań
  2. użytkownik w jednym momencie ma tylko jedną grupę zainteresowań (userID + SN)
  3. jako benchmark zróbmy CatBoosta na obecnych cechach (dostępnych z punktu widzenia uber_all i 1st-party), potem zróbmy model sekwencyjny (dataset sekwencyjny)

Model CVR - plan na później

::: block

  1. Z pixla wiemy kiedy był klik, więc możemy zasymulować recency; model z serwera powinien zwracać embedding zachowania usera, podczas aukcji ten embedding modyfikowalibyśmy poprzez recency (np. addytywnie) i to byłaby wycena (dokładniejsza). Wtedy to cechy z momentu nadania grupy zainteresowań + modyfikator czasu (recency),
  2. fuzzy matchowanie danych z klika (domena, device):
    1. z pixla wiemy, że o 16:00 pojawił się na CCC po kliknięciu w reklamę,
    2. wiemy, że o 15:59 ktoś z zrobił klika,
    3. wiemy, że ma przypisaną grupę ,
  3. idealnie byłoby mieć w uber_all event “przyszedłem z klika w reklamę”, ale prawdopodobnie możemy tę informację wyciągnąć już teraz.

Przypisywanie grup zainteresowań - plan

  • obecnie nadajemy grupę zainteresować jako userID + SN
  • spinamy flow
  • embeddujemy zachowanie użytkownika, klastrujemy embeddingi otrzymując grupę zainteresowań

good luck!

Graph View