Wymagane zmiany:
- Utworzenie panelu do ustawiania docelowej marży rzeczywistej.
Proponowane kroki do 1. iteracji:
- (Kontroler, analityk) Stworzenie symulacji potrzebnych do testowania kontrolerów:
- Pobranie danych o aukcjach (wszystkie wygrane i przegrane)
- Dla każdej aukcji symulacja najwyższej ceny spośród innych bidderów. Sprawdzenie rozkładu różnic między naszą cenę a ceną innego biddera dla częściowych danych, które mamy.
- Stworzenie mechanizmu z danych powyżej, który pozwoli nam zasymulować które aukcje zaczniemy wygrywać a które przegrywać po tym jak kontroler zmieni wycene (obniżając lub podwyższając je).
- (uber_all, dev) Dodanie do uber_all kolumny ze stawką z chwili konwersji
- (Kontroler, analityk) Zaprojektowanie i przetestowanie offline kontrolera na symulacjach z punktu wyżej
- dobranie parametrów
- symulacja i analiza sytuacji, w której klient zmienia stawkę - jak to wpływa na kontroler, jak szybko on się dostosowuje, jak szybko zjadamy górkę pieniędzy
- (bidData + bidder, dev). 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 powinniśmy zmigrować dane z bidData do nowej tabeli z poprawnie założonymi indeksami.
- (Kontroler, analityk) Zapakowanie kontrolera w DAG i odpalenie cyklicznego przeliczenia na airflow; pobieranie danych o docelowej marży z zewnętrznego systemu
- (Bidder, dev) Uwzględnienie w wycenie poprawki wyliczonej przez kontroler, dla ustalonych ssp i klientów, kontroler powinien być łatwo wyłączalny (growthbook)
Uwaga: olewamy stawki agencyjne, olewamy iFrameCreated, zakładamy, że nie płacimy na koniec miesiąca wpartnerowi