Aspekty sieciowe systemów RTB

Prezentacja na temat: "Aspekty sieciowe systemów RTB"— Zapis prezentacji:

1 Aspekty sieciowe systemów RTB
dr inż. Andrzej Szwabe Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej

2 Wybrane źródła Michael Greene, The Forrester Wave: Sell-Side Platforms, Forrester Research, Q1 2012, January 3, 2011 DoubleClick Ad Exchange Real-Time Bidding Protocol, August 30, 2012 The Arrival of Real-Time Bidding, Google White Paper, "OpenRTB API Specification Version 2.4", FINAL DRAFT, March 2016, RTB Project, OpenRTB Dynamic Native Ads API Specification Version 1.1, , March 2016, RTB Project, "Native Advertising Overview. Q2 2016", Don Butler, Nima Wedlake, Mark Prior, A. Barth, HTTP State Management Mechanism, Internet Engineering Task Force (IETF), RFC 6265, April 2011

3 Plan wykładu Znaczenie rynkowe technologii Real-Time Bidding (RTB)
Systemy RTB: terminologia i architektura Środowisko systemu ad exchange Przykładowa platforma ad exchange: DoubleClick Koncepcja automatycznej aukcji RTB Dane dostępne systemowi DSP w modelu RTB Protokoły i interfejsy systemów RTB Ciasteczka jako środek identyfikacji użytkownika Sesja systemu RTB Mechanizm dopasowywania („kojarzenia”) ciasteczek Protokoły interfejsów systemu RTB ProtoBufs - protokół serializacji danych w komunikatach RTB Możliwość synergii między RTB i cloud computing Przykłady systemów RTB: RTBkit, Datacratic RTB Optimizer Podsumowanie

4 Znaczenie rynkowe technologii RTB

5

6

7

8

9

10

11

12 eMarketer, kwiecień 2013: "RTB Ad Spend Continues Robust Growth
eMarketer, kwiecień 2013: "RTB Ad Spend Continues Robust Growth." "Nearly one in five display ad dollars this year to go to RTB."

13 Systemy RTB: koncepcja, terminologia i architektura

14 Koncepcja automatycznej aukcji RTB (1/2)

15 Koncepcja automatycznej aukcji RTB (2/2)

16 „RTB = Real-time Ad exchange”
Platforma RTB to zautomatyzowane narzędzie do handlu powierzchnią u wielu wydawców przez wielu reklamodawców jednocześnie w modelu aukcyjnym. Wydawca 1 KLIENCI POWIERZCHNIA Aukcja Wydawca 2 Portal Sieć reklamowa W tym modelu klienci (za pośrednictwem systemu RTB) ustalają warunki, na jakich chcą kupić daną odsłonę u danego wydawcy.

17 „RTB = Real-time Ad exchange”

18 Środowisko systemu ad exchange: terminologia
Wydawcy Reklamodawcy Supply Side Platform Demand Side Platform Ad exchange SSP Demand Side Platform Private adexchange Agency Trading Desk

19 Przykładowa platforma ad exchange: DoubleClick

20 Dane dostępne systemowi DSP w modelu RTB (1/3)
Proces decyzyjny realizowany przez podsystem DSP „reprezentuje interes nabywcy powierzchni”. reklamowej”

21 Dane dostępne systemowi DSP w modelu RTB (2/3)

22 Znaczenie rynkowe technologii RTB

23 Systemy RTB: protokoły i interfejsy

24 Ciasteczka jako środek identyfikacji użytkownika
A. Barth, HTTP State Management Mechanism, Internet Engineering Task Force (IETF), RFC 6265, April 2011

25 Sesja systemu RTB (1/2) (1) Użytkownik końcowy wchodzi na stronę WWW wydawcy. (2) Web serwer Wydawcy wysyła odpowiedź zawierającą kod HTML, który m.in. wskazuje przeglądarce gdzie znajdują się treści strony WWW (3). Część kodu HTML przesłanego do przeglądarki zawiera link określany jako "ad tag" (4). W przypadku systemu RTB link ten wskazuje pewien zasób na serwerze SSP jednocześnie służąc przekazaniu do SSP (5) danych o ID Wydawcy, ID serwisu Wydawcy oraz rozmiarze powierzchni reklamowej. Wraz z tymi danymi to samo zapytanie HTTP (5) zwykle (w większości przypadków!) zawiera też nagłówek HTTP stanowiący ciasteczko identyfikujące przeglądarkę w serwisie SSP. Serwer SSP inicjuje aukcję RTB (6) informując o ofercie aukcyjnej platformę RTB (np. Google DoubleClick ADX), która rozsyła tę informację (przez tzw. „rurę RTB”) do tych (stowarzyszonych z nią) serwerów DSP, których aktualna konfiguracja odpowiada cechom zgłoszonej aukcji (7).

26 Sesja systemu RTB (2/2) Na podstawie danych przekazanych przez platformę RTB systemy DSP dokonują automatycznej (zwykle trwającej kilkadziesiąt ms) wyceny oferty (ogłoszonej aukcji), a następnie przesyłają wynik tej wyceny do platformy RTB wchodzącej w skład infrastruktury SSP (8) wraz z adresem przekierowania do potencjalnie (w przypadku „wygrania” aukcji) prezentowanej reklamy (ang. ad redirect). Platforma RTB wybiera ofertę zgłoszoną przez jednego z DSP (9), a następnie przekazuje przeglądarce użytkownika przekierowanie do ostatecznie prezentowanej reklamy (10). Kolejne kroki procesu odpowiadają tradycyjnemu (tj. statycznemu) modelowi reklamy internetowej określanemu jako third party ad serving: przeglądarka wysyła żądanie do DSP uprzednio „wskazanego” przez SSP (11), system DSP odpowiada przekierowaniem do serwera reklam (12). Ostatecznie przeglądarka wysyła żądanie pobrania reklamy (13) i otrzymuje ją (14).

27 Mechanizm dopasowywania („kojarzenia”) ciasteczek
How cookie matching works To build an association in the Match Table, the buyer must serve a tag provided by Google, called the Match Tag. The Match tag can be served with the buyer's ads, or it can be placed on its web properties outside of ads. It is structured as follows: <img src=" />Here 1234 would be replaced by the buyer identifier supplied by Google. The buyer should only serve this tag if the buyer does not already have a match for this user (or if that entry is stale). Upon receiving the request for the tag from the user's browser, Google issues a 302 redirect to the buyer. This 302 redirect includes the Google User ID and a version number in the URL, and the buyer cookie in the request headers. The buyer supplies the base URL, and Google adds URL parameters. For example, the buyer could supply this base URL: could then redirect to a URL like this: Google User ID passed through the google_gid parameter is an unpadded URL-safe base64-encoded string. We recommend storing the exact string returned by the Cookie Matching Service in the match table. Note: The google_user_id field in the BidRequest protocol buffer corresponds to the Google User ID returned by the Cookie Matching Service.The google_cver parameter indicates a numeric version number for the Google User ID. Google may infrequently change the cookie obfuscation scheme, at which point thegoogle_cver value will be increased. The buyer receives this redirect, which includes the buyer cookie in the request headers, and updates the Match Table with the association between this buyer cookie and the Google User ID. The buyer must then serve a 1x1 invisible image pixel to the user's browser, or return a 204 No Content response. Entries are added to the Match Table at the rate at which Match Tags are served to unique users. This process is illustrated by the diagram below. Each request or response is represented by an arrow, and the data items that accompany the request or response are listed in parentheses. <img src=" />

28 Scenariusz 1: wykasowane ciasteczka
Jane clears her cache of all cookies. She then visits the homepage of ExampleNews.com. Here’s what happens: ExampleNews.com renders, and calls ads from Google (DoubleClick for Publishers). Because the ad unit is eligible for dynamic allocation, Ad Exchange sends bid requests to FinestDSP (among other DSPs). FinestDSP processes the bid request in its bid engine, and sends its bid response to Ad Exchange FinestDSP wins the auction, and sends an ad and a match tag (pixel) to Ad Exchange. Ad Exchange serves FinestDSP’s ad and match tag to Jane, and also sets Jane’s DoubleClick cookie. The match tag calls Google's Cookie Match Service. The Cookie Match Service reads Jane's DoubleClick cookie, and sends a redirect to FinestDSP with google_user_id set. The browser loads FinestDSP's URL. FinestDSP generates a cookie, which it stores against Jane's google_user_id in its match table. FinestDSP drops its cookie in Jane's browser and responds to the redirect with an invisible 1x1 pixel. ExampleNews.com renders, and calls ads from Google (DoubleClick for Publishers).Because the ad unit is eligible for dynamic allocation, Ad Exchange sends bid requests to FinestDSP (among other DSPs).FinestDSP processes the bid request in its bid engine, and sends its bid response to Ad ExchangeFinestDSP wins the auction, and sends an ad and a match tag (pixel) to Ad Exchange.Ad Exchange serves FinestDSP’s ad and match tag to Jane, and also sets Jane’s DoubleClick cookie.The match tag calls Google's Cookie Match Service.The Cookie Match Service reads Jane's DoubleClick cookie, and sends a redirect to FinestDSP with google_user_id set.The browser loads FinestDSP's URL.FinestDSP generates a cookie, which it stores against Jane's google_user_id in its match table.FinestDSP drops its cookie in Jane's browser and responds to the redirect with an invisible 1x1 pixel.

29 Scenariusz 2: zidentyfikowane („skojarzone”) ciasteczka
Scenario 2: Buyer and DoubleClick cookies A week after Scenario I, Jane visits ExampleNews.com again. Now that Jane has both buyer and DoubleClick cookies on her machine, let’s see how matching works. The the web page renders, executing the HTML code's call to Google for ads. During the ad auction, DoubleClick Ad Exchange sends a bid request to an RTB buyer, FinestDSP, giving that buyer the option of bidding on the impression. The buyer receives the bid request with impression information and the google_user_id. FinestDSP looks up the google_user_id in its match table to find the cookie created a week earlier (in Scenario I). Based on the information associated with its cookie, FinestDSP decides to bid on the impression, and wins the auction. Jane might see an ad tailored to her interests, again based on information that FinestDSP possesses. ExampleNews.com renders, and calls ads from Google (DoubleClick for Publishers).Because the ad unit is eligible for dynamic allocation, Ad Exchange sends bid requests to FinestDSP (among other DSPs).FinestDSP processes the bid request in its bid engine, and sends its bid response to Ad ExchangeFinestDSP wins the auction, and sends an ad and a match tag (pixel) to Ad Exchange.Ad Exchange serves FinestDSP’s ad and match tag to Jane, and also sets Jane’s DoubleClick cookie.The match tag calls Google's Cookie Match Service.The Cookie Match Service reads Jane's DoubleClick cookie, and sends a redirect to FinestDSP with google_user_id set.The browser loads FinestDSP's URL.FinestDSP generates a cookie, which it stores against Jane's google_user_id in its match table.FinestDSP drops its cookie in Jane's browser and responds to the redirect with an invisible 1x1 pixel.

30 Protokoły interfejsów systemu RTB (1/2)
Funkcja Interfejs Prekonfiguracja kampanii SOAP API  (UI strony nabywającej powierzchnie reklamowe) Konfiguracja parametrów „celowania” („targetowania”) reklam w ramach danej kampanii Składanie reklam przeznaczonych do emisji w ramach tzw. „statycznych aukcji” (ang. static bidding) Pozyskiwanie danych o ofertach (aukcjach) REST API Konfiguracja konta użytkownika platformy RTB Składanie reklam przeznaczonych do emisji w ramach aukcji dynamicznych (tj. aukcji RTB) Interakcje związane z uzyskiwaniem danych o aukcjach (ang. bid requests) od platformy Ad Exchange oraz „podejmowaniem decyzji” przez system DSP RTB Protocol Konfiguracja kampanii realizowanej w modelu RTB Pre-Targeting

31 Protokoły interfejsów systemu RTB (2/2)
Nazwa funkcji (metody REST API) Opis funkcji Użycie metod HTTP list Uzyskanie listy wszystkich kont, do których ma dostęp aktualnie uwierzytelniony użytkownik GET ”on a collection URI” get Uzyskanie konkretnego zasobu dostępnego użytkownikowi danego konta GET ”on a resource URI” update Aktualizacja (zapis) konkretnego zasobu dostępnego użytkownikowi danego konta PUT ”on a resource URI”

32 {   "kind": "adexchangebuyer#pretargetingConfig",   "configId": long,   "billingId": long,   "configName": string,   "isActive": boolean,   "creativeType": [     string   ],   "dimensions": [     {       "width": long,       "height": long     }   ],   "languages": [     string   ],   "geoCriteriaIds": [     long   ],   "excludedGeoCriteriaIds": [     long   ],   "supportedCreativeAttributes": [     long   ],   "vendorTypes": [     long   ],   "placements": [     {       "type": string,       "token": string     }   ],   "excludedPlacements": [     {       "type": string,       "token": string     }   ],   "verticals": [     long   ],   "excludedVerticals": [     long   ],   "userLists": [     long   ],   "excludedUserLists": [     long   ],   "excludedContentLabels": [     long   ],   "platforms": [     string   ],   "mobileCarriers": [     long   ],   "mobileDevices": [     long   ],   "mobileOperatingSystemVersions": [     long   ] }

33 ProtoBufs - protokół serializacji danych w komunikatach RTB
Opracowany w 2011 r. Protocol Bufers (skrótowo: ProtoBufs) jest protokołem binarnej serializacji danych i jako taki może być podstawą do tworzenia rozwiązań z zakresu RPC. Został zaprojektowany tak, aby być wydajniejszym („oszczędniejszym”) i szybszym od XML'a. Podobnie jak inne, analogiczne technologie (CORBA), korzysta z języka opisu interfejsów IDL i na jego podstawie tworzy kod źródłowy służący następnie realizacji funkcji wymiany danych. Obecnie Protocol Bufer jest dostępny w formie otwartego kodu w językach: C++, Java i Python.

34 Przykład definicji IDL
message Point { required int32 x = 1; required int32 y = 2; optional string label = 3; } message Line { required Point start = 1; required Point end = 2; message Polyline { repeated Point point = 1; optional string label = 2;

35 Możliwość synergii między RTB a cloud computing
Ułatwienie procesu uruchomienia systemu RTBkit (systemu klasy RTB DSP) w środowisku usługi Amazon Elastic Compute Cloud (EC2) - jako "Amazon instance" na bazie obrazu maszyny wirtualnej ami-7b531a12 Ograniczona stosowalność predefiniowanego obrazu AMI (Amazon Machine Image) do użycia w tzw. scenariuszu produkcyjnym ("available in the US East (N. Virginia) region: the right packages are installed and the user-level setup has already been done for the rtbkit user(...) NOTE: This AMI doesn't employ the more recent EC2 HVM instance type and doesn't use the more recent option of SSD-backed EBS volumes, making it appropriate for development but less appropriate for production at anything above low qps.”) Google Open Bidder – odmiana usługi Google Compute Engine (usługi „obliczeń w chmurze”) dedykowana realizacji funkcji podsystemu DSP w ramach systemu RTB Google DoubleClick Dostosowane maszyny wirtualne z systemem Linux Możliwość tworzenia całego „stosu” tzw. bidders w celu skonstruowania bardziej złożonej „logiki” (bidding logic) Możliwość uruchamiania bidders na serwerach położonych w pobliżu platformy RTB Google DoubleClick („Now buyers can focus on developing new and innovative bidding logic instead of worrying about the complexity of scaling to over 250,000 qps while responding in under 100ms.”)

36 Standaryzacja systemów RTB: IAB OpenRTB (1/5)
Poglądowa prezentacja komunikacji między systemami tzw. ekosystemu RTB wg IAB OpenRTB

37 Standaryzacja systemów RTB: IAB OpenRTB (2/5)
Prezentacja sekwencji komunikatów między podsystemami tzw. ekosystemu RTB ze strony popytowej (Bidder – podystem wchodzący w skład systemu Demand Side Platform) i podażowej (RTB Exchange) wg IAB OpenRTB

38 Standaryzacja systemów RTB: IAB OpenRTB (3/5)
Od 2015 r. standaryzacja IAB OpenRTB obejmuje również nabywanie powierzchnii typu native

39 Standaryzacja systemów RTB: IAB OpenRTB (4/5)
Od 2015 r. standaryzacja IAB OpenRTB obejmuje również nabywanie powierzchnii typu native

40 Standaryzacja systemów RTB: IAB OpenRTB (5/5)
Komunikaty niektórych z platform ad exchange (np. OpenX) są w dużej mierze zgodne ze specyfikacją OpenRTB

41 Budowa przykładowego systemu RTB (1/2)
Przykładowy system zewnętrznej (3rd-party) optymalizacji działania platformy RTB Demand Side Platform (Datacratic RTB Optimizer) Bids API jest interfejsem zgodnym ze specyfikacją OpenRTB Outcomes API odpowiada Events API

42 Budowa przykładowego systemu RTB (2/2)

43 Budowa systemu klasy DSP o otwartym kodzie: RTBkit (1/4)

44 Platforma typu ad exchange wysyła zapytanie RTB (bid request), które trafia do komponentu Router za pośrednictwem wtyczki parsującej typu exchange connector (odpowiedniej dla danej platformy ad exchange). Komponent Router przekazuje zapytanie RTB (bid request) do komponentu Augmenter (wzbogacającego zapytania o dodatkowe dane posiadane przez operatora platformy DSP). Komponent Augmenter przekazuje (zwraca) wzbogacone zapytanie RTB („bid request +”, BR+) do komponentu Router. Komponent Router przekazuje wzbogacone zapytanie RTB („BR+”) do komponentu decyzyjnego Bidding Agent (jednego z puli aktywnych komponentów BA). Komponent Bidding Agent przeprowadza oszacowanie wartości odsłony (tj. potencjalnej wartości „emisji” reklamy) a następnie przesyła estymatę do komponentu Router . Komponent Router przekazuje estymatę wartości odsłony do platformy ad exchange w postaci komunikatu Bid (tj. bid response). Platforma typu ad exchange (lub serwer treści reklamowych Ad Server) wysyła (opcjonalnie) za pośrednictwem wtyczki Ad Server Connector do komponentu Router komunikat powiadomienia o wygranej aukcji; wtyczka Ad Server Connector przekazuje ten komunikat do usługi Post-Auction Service Usługa Post-Auction Service przekazuje komunikat powiadomienia o wygranej aukcji (win notification) do (właściwego) komponentu decyzyjnego Bidding Agent.

45 Budowa systemu klasy DSP o otwartym kodzie: RTBkit (2/4)

46 Budowa systemu klasy DSP o otwartym kodzie: RTBkit (3/4)

47 Budowa systemu klasy DSP o otwartym kodzie: RTBkit (4/4)

48 Skalowalność mikrousługowej architektury RTBkit (1/3)
Możliwe wdrożenie na pojedynczym serwerze wirtualnym (Single Node Deployment) Zalecane wdrożenie w środowisku usługi Amazon EC2 (wiodącej usługi VSH) Przykładowa konfiguracja (Amazon AWS EC2 C3.8xlarge): Procesory Intel Xeon E v2 (Ivy Bridge), 32 vCPU, 60 GB RAM, SSD 2 x 320 GB Na rynku amerykańskim taka instalacja zapewnia DSP skalę działalności o miesięcznych wydatkach na zakup powierzchni rzędu $100,000.

49 Skalowalność mikrousługowej architektury RTBkit (2/3)
Wdrożenie na klastrze n serwerów wirtualnych (Multi Node Deployment) Zalecane wdrożenie w środowisku usługi Amazon EC2 Usługi typu singleton i węzły Real-Time (RT) na serwerze wirtualnym Amazon AWS EC2 C3.8xlarge Skalowalność dzięki zrównolegleniu węzłów typu Real-Time Node na n serwerów HAProxy dla węzłów RT Uzupełniający węzeł agregacji danych Carbon/Graphite na serwerze M3.xlarge (2 rdzenie, 3.69GB RAM)

50 Skalowalność mikrousługowej architektury RTBkit (3/3)
Wdrożenie na grupie klastrów serwerów wirtualnych (Multi-Node Multi-DC (Data Center) Deployment) Dla każdego data center węzły dla usług typu singleton oraz węzły typu Real-Time analogiczne jak w przypadku wdrożenia klasy Multi Node Deployment Pojedyncza brama rozkładająca ruch zapytań typu bid request (HAProxy load balancer) przypadająca na jedno data center Lokalne usługi Carbon i Graphite na każdym z wirtualnych serwerów uzupełnione o jedną globalną usługę agregującą dane dla całej grupy data centers

51 REST w praktyce: scenariusz aplikacyjny usługi RTBkit Banker
Przeznaczenie usługi Usługa służąca rozliczeniom w ramach realizacji wielu równoczesnych kampanii wielu reklamodawców w ramach jednej platformy Demand Side Platform (DSP) działającej w środowisku Real-Time Bidding (RTB) Składnik architektury mikrousługowej systemu RTBkit - wiodącego projektu otwartego oprogramowania dla platform DSP w technologii RTB) Zakres funkcji usługi Ograniczone respektowanie zasad REST co do funkcjonalności usługi -> usługa nazywana „REST API” brak bezpośredniego dostępu do niektórych zasobów ograniczone zastosowanie zasady HATEOAS

52 Konceptualizacja na użytek usługi RTBkit Banker
Ontologiczna prostota „konceptów” API Pojedyncza klasa: konto (ang. account) w systemie RTBkit Banker Możliwość budowy hierarchii zasobów – poddrzewa kont „Wrażliwość” i złożoność zależności między subkontami częściowo „ukryta” przed klientem

53 Zasada działania usługi RTBkit Banker

54 Półformalna definicja usługi
Treść strony WWW jako „definicja” usługi [ Lakoniczna specyfikacja sposobu użycia parametrów zapytań HTTP (przesyłanych w adresach URL): „parameters should be specified as URL query e.g. POST /v1/accounts?accountType=budget&accountName=helloworld” Klasyfikacja zasobów wg ich dostępności z użyciem metod HTTP: GET /v1/accounts parameters: maxDepth: an integer describing the maximum length at which keys will be sought (default: unlimited) accountPrefix: a string that specifies the prefix against which the returned account names will be matched POST /v1/accounts accountType: a string describing the account type to be created ("spend" or "budget") accountName: a string describing the account name to be created

55 Podsumowanie Model Real-Time Bidding wobec:
modelu tradycyjnej reklamy internetowej, modelu usługowego SaaS, modelu architekturalnego SOA

56 Dziękuję za uwagę i proszę o pytania.