System kontroli budżetu reklam RTB

Kontrolowanie wydatków reklamowych to główny element każdej platformy DSP. Jeśli nie jest zarządzany prawidłowo, budżet zostanie przekroczony lub nie zostanie wyczerpany – oba przypadki są niekorzystne dla reklamodawców.

Jeśli budżet nie zostanie wyczerpany, kampania reklamodawcy nie osiąga odpowiedniej liczby odbiorców. Jeśli budżet zostanie przekroczony, reklamodawca musi pokryć nieprzewidziane koszty i marnuje wówczas szansę na pokazanie reklam odpowiedniej publiczności za te pieniądze.

Na dowolnej stronie internetowej może być kilka miejsc na reklamy. Każde taki ad slot wysyła żądanie do serwera reklam wydawcy, który z kolei wysyła żądanie do SSP/giełdy reklamowej, a następnie do wielu DSP.

Gdy DSP otrzymuje sygnał, musi odpowiedzieć zazwyczaj w ciągu 250 ms.

Ten proces zachodzi miliardy razy dziennie w całym internecie.

Ze względu na niezwykle krótkie ramy czasowe DSP muszą zapewnić, że budżety ich reklamodawców są zarządzane poprawnie.

Zazwyczaj między czasem odpowiedzi na żądanie a otrzymaniem informacji przez DSP, że reklama została wyświetlona, mija kilka sekund. Opóźnienie to może powodować przekraczanie budżetu, gdy istnieje wielu bidujących wywołujących duży ruch (tj. żądania).

Zobacz, co dzieje się na powyższym diagramie:

1. Wydawca wysyła żądanie reklamy do SSP/giełdy reklam.
2. SSP/giełda reklam wysyła żądanie licytacji do licytującego DSP.
3. Jeśli oferta pasuje do kampanii w DSP, licytujący wysyła ofertę (np. CPM 1,05 USD) i znacznik reklamy.
4. Zakładając, że DSP wygrywa wyświetlenie, SSP/giełda reklam wysyła znacznik reklamy DSP do wydawcy.
5. Wydawca ładuje znacznik reklamy i wysyła żądanie pobrania kreatywu(reklamy).
6. Serwer reklam wysyła kreatyw do wydawcy i wyświetla go użytkownikowi.
7. Tracker rejestruje dane o wyświetleniu i kliknięciu (jeśli dotyczy).
8. Tracker wysyła informacje o wyświetleniu w celu aktualizacji cappingu.
9. Tracker wysyła dane zdarzenia do bazy danych raportów kampanii, które zostaną użyte do generowania raportów.

W takim ustawieniu nie ma właściwego i efektywnego sposobu na zarządzanie budżetem, co oznacza, że budżet będzie przekraczany.

Przyjrzyjmy się trzem sytuacjom:

1. Szerokie targetowanie

Tworząc kampanię w DSP, reklamodawcy i AdOpsi określają parametry targetowania, takie jak lokalizacja, rodzaj urządzenia czy rozmiar reklamy.

Jeśli targetowanie jest zbyt szerokie, to bidder dopasuje dużą liczbę żądań licytacji do kampanii. To może wystąpić od razu lub w ciągu kilku milisekund.

Chociaż szerokie targetowanie zazwyczaj nie jest problemem, bez właściwego systemu zarządzania budżetem reklamodawca prawdopodobnie przekroczy budżet, ponieważ nie zostanie poinformowany o wygranych wyświetleniach i dlatego nie będzie mógł zaktualizować budżetu przed kolejnym wyświetleniem reklamy.

2. Kampanie digital out-of-home (DOOH)

Jeśli DSP jest zintegrowany z platformą DOOH, gdzie reklamodawcy prezentują swoje reklamy na cyfrowych billboardach, to w zależności od licznych czynników, takich jak konfiguracja platformy DOOH i proces zakupu mediów, może wystąpić długi czas oczekiwania na otrzymanie informacji, że reklama reklamodawcy została wyświetlona.

Opóźnienie to może wynosić od 15 minut do 48 godzin; w takim przypadku nie ma jak dokładnie śledzić budżetu.

3. Licytujący i bazy danych wydatków w różnych regionach

Ze względu na lokalizację DSP są takie sytuacje, gdzie licytujący i wydatki DSP będą znajdować się w tym samym regionie co SSP/giełda reklam (np. region AWS us-east-1).

Jednak może się zdarzyć, że różne komponenty DSP (np. bidder i baza danych wydatków) będą znajdować się w różnych regionach.

Ze względu na opóźnienia między różnymi centrami danych możliwe jest, że DSP przekroczy budżet, chyba że zostanie dodany odpowiedni komponent zarządzania budżetem.

Aby uniknąć przekraczania budżetu, stworzyliśmy ad banker. Komponent ten opiera się na algorytmie bankiera Edsgera W. Dijkstry.

Ad banker jest używany do zapewnienia optymalnego rozłożenia budżetu między wiele procesów (licytujących). Pozwala kilku licytującym na otrzymywanie i odpowiadanie na żądania licytacji w tym samym czasie, unikając przekraczania budżetu.

• Jednym z pierwszych zadań, które podjęliśmy w ramach tego projektu, było zoptymalizowanie backendu i bazy danych. Przeprojektowaliśmy strukturę bazy danych, aby umożliwić jej bardziej efektywne działanie i zwiększyć szybkość przetwarzania żądań wysyłanych z witryn sprzedawców.
• Nasza wiedza w tej dziedzinie i nasze doświadczenie w podobnych projektach pozwoliły nam zminimalizować krzywą uczenia się i skrócić czas poświęcony na planowanie projektu. Pozwoliło nam to szybko rozpocząć i utrzymać dynamiczne tempo budowania aplikacji.
• Używaliśmy mongoDB jako bazy danych, zapewniając stabilność, niezawodność i wydajność potrzebną do obsługi wielu funkcji i żądań.

Poniższy diagram ilustruje rolę ad bankera i sposób jego interakcji z innymi komponentami.

Widać tutaj flow z diagramu #1 w szerszym kontekście DSP. Wprowadzenie ad bankera do DSP zmienia ten flow:

Poniżej wyjaśniamy, co dzieje się na diagramie #2:

1. Wydawca wysyła żądanie reklamy do SSP/giełdy reklam.
2. SSP/giełda reklam wysyła żądanie stawki do DSP.
3. Jeśli oferta pasuje do kampanii w DSP, bidder prosi komponent o nazwie cashier o zasoby do złożenia oferty (np. CPM 1,05 USD).
4. Jeśli zasoby są dostępne, bankier przydziela je do biddera w większej ilośći, aby bidder mógł ich użyć w przyszłych aukcjach.
5. Jeśli licytujący otrzyma zasoby od bankiera, wysyła z powrotem ofertę i znacznik reklamy.
6. Zakładając, że DSP wygrywa wyświetlenie, SSP/giełda reklam wysyła znacznik reklamy DSP do wydawcy.
7. Wydawca wczytuje znacznik reklamy i wysyła żądanie do serwera reklam DSP (zarówno wewnętrznego, jak i zewnętrznego).
8. Serwer reklam wysyła kreatyw do wydawcy i wyświetla go użytkownikowi.
9. Znacznik reklamy wysyła żądanie do trackera z danymi o wyświetleniu i kliknięciu (jeśli dotyczy).
10. Tracker informuje bankiera, że wyświetlenia zostało obsłużone i budżet jest aktualizowany. Jeśli tracker nie informuje bankiera o zdarzeniu w określonym przedziale czasowym, zasoby są uważane za niewykorzystane.
11. Tracker przesyła informacje o wyświetleniu do zaktualizowania cappingu.
12. Tracker przesyła dane zdarzenia do bazy danych raportowania kampanii, które zostaną użyte do generowania raportów.

W celu przetestowania wydajności ad bankera stworzyliśmy różne algorytmy.

Poniżej znajdują się wyniki z pierwszego testu.

Naive. Algorytm bez ad bankera: zakłada, że cały budżet jest dostępny do licytacji, ponieważ jeszcze nie otrzymał żądań wyświetleń i nie zaktualizował budżetu.

Bankier z rezerwacjami na 1 minutę: oznacza, że rezerwacja z bankiera nie może być ponownie użyta w ciągu pierwszej minuty od jej zwolnienia.

…zwalnianie najwcześniejszej rezerwacji na wyświetlenie i …zwalnianie rezerwacji w odpowiednim czasie licytacji: odnosi się to do tego, jak przypisujemy wyświetlenie do rezerwacji bankiera.

Uwaga: Powyższe testy przeprowadzono przy użyciu modelu dystrybucji budżetu “as-soon-as-possible” (ASAP). Wyniki mogą się różnić, jeśli użyty zostanie inny model, tak jak model “pacing”.

Współczynniki wydatków reprezentują, ile budżetu kampanii zostało wydane przez dane algorytmy.

Idealny współczynnik wydatków to 1, co oznacza 100% budżetu kampanii.

Maksymalne nadmiarowe wydatki algorytmu naive wyniosły 1,372, co dla budżetu $10,000 przekłada się na nadwyżkę w wysokości $3,720.

Poniższa tabela reprezentuje przekroczenie budżetu, jaki każdy algorytm wygenerował podczas fazy testowej.

Uwaga dotycząca 0% “nadwydatków”

Chociaż celem bankiera jest zminimalizowanie nadwydatków, osiągnięcie 0% jest mało prawdopodobne.

Jest to sytuacja typowa dla platform RTB z powodu fluktuacji w ruchu, rodzaju kreatywów i opóźnień w otrzymywaniu powiadomień o wygranej lub wyświetleniu.