Frequency Capping bei Protected Audience

Frequency Capping ist eine Werbepraktik, mit der die Anzahl der Anzeigen aus einer bestimmten Kategorie begrenzt wird, die einem Nutzer in einem bestimmten Zeitraum präsentiert werden. Frequency Capping verbessert die Endnutzererfahrung, da Anzeigenimpressionen immer aktuell und interessant bleiben. Außerdem können Werbetreibende so ihre Werbeausgaben besser verwalten.

In diesem Vorschlag wird beschrieben, wie mit Protected Audience unter Android Frequency Capping-Funktionen genau und datenschutzfreundlich implementiert werden können.

Protected Audience implementiert das Frequency Capping durch die Kombination von zwei Funktionen: die On-Device-Speicherung von Zählern für anzeigenspezifische Ereignisse und die Möglichkeit, Anzeigen anhand einer vordefinierten Reihe von Filterstrategien zu filtern. Mit Frequency Capping können Werbetreibende einen Zählergrenzwert für eine Summe von Histogrammwerten für einen bestimmten Zeitraum angeben.

Zähler sind für jede Kombination aus Geräteprofil, Ad-Tech und Zählerschlüssel eindeutig. Jede Anzeige sollte eine Reihe von Zählerschlüsseln enthalten, die verwendet werden, wenn eine Ansicht oder Impression für die Anzeige registriert wird. Für jeden Schlüssel speichert Protected Audience eine Reihe von Zählern. Jeder Zähler erfasst alle anzeigenspezifischen Ereignisse, die innerhalb eines bestimmten Zeitintervalls auftreten. Die Zähler auf dem Gerät werden erhöht, wenn eine Impression oder ein Aufruf erfolgt. Die Zählerdaten werden auf dem Gerät gespeichert. Die genaue Dauer der Speicherung wird später festgelegt.

Die Logik für das Filtern von Anzeigen im Workflow für die Anzeigenauswahl von Protected Audience hat Zugriff auf Zähler, Remarketing-Anzeigen und kontextbezogene Anzeigen. Dadurch kann das Frequency Capping von Protected Audience mit allen Arten von Anzeigenanfragen verwendet werden.

Hinweis: Die Anzeigenfilterung ist nur in der Privacy Sandbox für Android verfügbar. In der Protected Audience-Implementierung von Chrome ist kein Mechanismus zum Filtern von kontextbezogenen Anzeigen ohne Protected Audience-Targeting enthalten. Dieses Angebot umfasst nur Unterstützung auf der Käuferseite. Bei Bedarf werden wir die Sell-Side-Unterstützung zu einem späteren Zeitpunkt hinzufügen.

Das Frequency Capping für Protected Audience unterstützt eine Vielzahl von Anforderungen, darunter:

  • Echtzeitfilterung mit minimaler serverseitiger Verzögerung, wenn On-Device-Zähler aktualisiert werden.
  • Flexible Hierarchie von Schlüsseln, einschließlich einzelner Anzeigen, Kampagnen oder anderer Gruppierungen.
  • Übereinstimmung mit anderen Frequency Capping-Methoden ohne Abhängigkeit von der AdID.
  • Funktioniert app-übergreifend in einem bestimmten Geräte-Nutzerprofil.
  • Genaue und vollständige Zähler.
  • Unterstützung benutzerdefinierter Definitionen von Anzeigenereignissen wie Aufrufen oder Impressionen
  • Eine Funktion für Remarketing- und kontextbezogene Anzeigen.

So richten Sie die Häufigkeitsbegrenzung ein:

Schritt 1: Informationen zum Frequency Capping zu Anzeigen hinzufügen

Bei kontextbezogenen Anzeigen und Remarketing-Anzeigen werden relevante Histogrammzähler angegeben, die bei einer Aufrufung oder Impression aktualisiert werden sollen. Dazu wird das Feld ad_counter_keys verwendet, das eine Liste mit beliebigen Ganzzahlen enthält. Das Feld ist nicht im Feld metadata enthalten, das von Protected Audience nicht geparst wird.

Im folgenden Beispiel sehen Sie das Datenformat für das Feld adsData in AdSelectionConfig. Für das Remarketing entspricht das Format der Liste von Anzeigen für eine bestimmte benutzerdefinierte Zielgruppe dem Inhalt des Felds ads im folgenden Beispiel:

'adsData': [
  {
    "buyer": "ads.example.com",
    "ads": [
      {
        'render_url': 'exampleUrl',
        'metadata': {...},   /* metadata are opaque to Protected Audience are
                                required to be in valid JSON format */
        'ad_counter_keys': [1234, 5678]
      }]
  }]
}

Schritt 2: Aufruf oder Impression registrieren

Ad-Tech-Anbieter können die Methode updateAdCounterHistogram aufrufen, um Ereignisse zu registrieren, die für das Frequency Capping verwendet werden. Eine Methode kann für Schlüssel, die in der eventType der Gewinneranzeige angegeben sind, wiederholt für dasselbe Ereignis aufgerufen werden.

void updateAdCounterHistogram(@EventType eventType, long adSelectionId)

Eingaben:

  • eventType:Gibt an, ob ein Ereignis als Aufruf, Impression, Klick oder Gewinn des Anzeigenauswahlprozesses gezählt wird.
  • adSelectionId:ID-Werte im AdSelectionOutcome-Objekt, die von selectAds-Aufrufen zurückgegeben werden.

Mit dem updateAdCounterHistogram-Aufruf wird das Histogramm für die Gruppe von Schlüsseln aktualisiert, die entweder als Teil der Remarketing-Anzeigen definiert sind, die von einem CustomAudience abgerufen werden, oder als Teil der kontextbezogenen Anzeigen, die im AdSelectionConfig-Parameter für selectAds enthalten sind.

Wenn Sie davon ausgehen, dass die Anzeige in Schritt 1 die Gewinneranzeige einer AdSelection mit einem id-Wert von 9999 ist, werden durch einen Aufruf von updateAdCounterHistogram(FrequencyCapFilters.AD_EVENT_TYPE_VIEW, adSelectionId: 999) die Zähler für die folgenden drei primären Schlüssel erhöht:

  • {'ads.example.com', 1234, VIEW}
  • {'ads.example.com', 5678, VIEW}

Der Name der Ad-Tech-Plattform wird aus dem Käuferfeld übernommen, entweder aus kontextbezogenen Anzeigen oder aus benutzerdefinierten Zielgruppen, je nachdem, woher die Anzeigen stammen, die die Auktion gewonnen haben.

Bei Protected Audience für Android werden alle oben genannten Zähler für den Ereignistyp FrequencyCapFilters.AD_EVENT_TYPE_WIN für Anzeigen, die von einem selectAds-API-Aufruf zurückgegeben werden, automatisch erhöht. Dies entspricht funktional dem Hinzufügen des Arguments prev_wins zu browser_signals in generateBid in der Protected Audience-Implementierung von Chrome.

Schritt 3: Frequency Capping-Filterung mit Filtern implementieren

Für eine optimale Leistung wird die Filterfunktion für die Häufigkeitsobergrenze in AdServices ausgeführt. Protected Audience erkennt, ob eine Nachricht gefiltert werden muss, indem das Feld „filters“ im AdsData-Objekt gelesen wird. Eine Liste der Filter wird in frequency_cap angegeben. Die Werte für „key“, event_type und interval_in_seconds werden verwendet, um ein Histogramm von Ereignissen abzurufen, die für das Filtern und Protected Audience verwendet werden.

Filterinformationen können für Remarketing-Anzeigen, die von einer benutzerdefinierten Zielgruppe bereitgestellt werden, und für kontextbezogene Anzeigen als Teil des AdSelectionConfig-Objekts angegeben werden.

Bei kontextbezogenen Anzeigen mit Filtern für das Frequency Capping werden Anzeigen über das Feld „ads“ im AdSelectionConfig-Objekt übergeben. Anzeigen werden gefiltert und die Anzeige mit dem höchsten Gebot wird als Ergebnis des selectAds-Aufrufs zurückgegeben.

Bei Remarketing-Anzeigen mit Filtern für das Frequency Capping werden Anzeigen gefiltert, bevor die vom Käufer bereitgestellte generateBid()-JavaScript-Funktion aufgerufen wird.

Das folgende Beispiel zeigt eine Nachricht mit Filterung nach Häufigkeitsbegrenzung:

{
  'render_url': 'url',
  'metadata': {...},   /* metadata are opaque to Protected Audience and assumed
                        to be in valid JSON format */

  'ad_counter_keys': [1234, 5678],

  "filters": {
    "frequency_cap": {
      "view": [
        {
          "ad_counter_key": 1234
          "max_count": 10,
          "interval_in_seconds": 86400
        },
        {
          "ad_counter_key": 5678
          "max_count": 10,
          "interval_in_seconds": 86400
        },
      ],
      "win": [
        {
          "ad_counter_key": 1234
          "max_count": 5,
          "interval_in_seconds": 604800
        },
        {
          "ad_counter_key": 5678
          "max_count": 5,
          "interval_in_seconds": 345600
        },
      ]
    },

  // This field is only required in contextual ads and is used in
  // reportImpression calls to fetch the reportWin function.
  'reportingJS': "https://ads.example.com?reportWin.js"
}

Schritt 4: Berichte zu Gewinneranzeigen erstellen

Nach Abschluss der Anzeigenauswahl wird ein AdSelectionOutcome-Objekt mit renderUri und adSelectionId zurückgegeben, einer numerischen Kennung für den selectAds-Aufruf. Mit dieser ID kann die reportImpression API aufgerufen werden, die Berichte auf Ereignisebene unterstützt. In Beta 1 werden Berichte für Remarketing-Anzeigen unterstützt. In einer späteren Version wird die Methode auch für Berichte für kontextbezogene Anzeigen erweitert. Bei kontextbezogenen Anzeigen muss der Käufer angeben, wo die reportWin-Funktion während eines reportImpression-Aufrufs abgerufen werden kann. Dazu muss er in der Anzeigenstruktur ein zusätzliches Feld namens reportingJS verwenden, wie im vorherigen Beispiel gezeigt.

Best Practices für die Auswahl von Anzeigenkandidaten

Bei Protected Audience wird die Durchsetzung des Frequency Capping vom Server auf das Gerät verlagert. Gewonnene Gebote werden zwar mit der Privacy Sandbox gemeldet, Entwickler wissen aber nicht, warum eine Anzeige nicht ausgeliefert wird. Anzeigen werden möglicherweise nicht ausgeliefert, weil ein Gebot verloren wurde oder aufgrund von Frequency Capping. Da die Gründe für das Nicht-Gewinnen bestimmter Anzeigen nicht vollständig nachvollziehbar sind, ist bei Gebotssystemen zusätzlicher Aufwand erforderlich, um zu prüfen, ob optimale Anzeigen ausgeliefert werden. Mit diesen Best Practices können Sie die optimale Anzeigenauslieferung mit Protected Audience überprüfen.

Genügend Remarketing-Anzeigen schalten

Remarketing-Anzeigen können nicht pro Nutzer optimiert werden. Wenn ein Nutzer eine große Anzahl von Anzeigen aus einer benutzerdefinierten Zielgruppe sieht und die Anzeigenlimits niedrig sind, werden möglicherweise alle Anzeigen herausgefiltert. Remarketing-Anzeigen werden regelmäßig aktualisiert. Daher sollte genügend Anzeigeninventar das Frequency Capping durchlaufen, damit Remarketing-Anzeigen weiterhin ausgeliefert werden. Dies muss mit den Einschränkungen für die Größe der Anzeigen, die während des joinCustomAudience-Aufrufs und der täglichen Aktualisierung der benutzerdefinierten Zielgruppe angegeben werden können, in Einklang gebracht werden. Käufer müssen berücksichtigen, dass es während der Gebotsphase zu einer erhöhten Latenz kommen kann. Um die Auswirkungen dieser Probleme zu minimieren, wird die Filterung der Häufigkeitsbegrenzung vor dem Aufruf von generateBid durchgeführt.

Kontextbezogene Zähler auf dem Server beibehalten

Mit der serverseitigen Schätzung kann ein Entwickler ungefähre Schätzungen dafür erhalten, wann das Frequency Capping aktiv sein könnte. Diese Schätzungen können darauf hinweisen, dass eine Anzeige wahrscheinlich den Frequency-Capping-Schwellenwert erreicht hat. Sie sollte daher mit mehr Anzeigenkandidaten gesendet oder ganz entfernt werden.

Mehrere Anzeigenkandidaten in der kontextbezogenen Antwort senden

Sie sollten vor einer Protected Audience-Auktion mehrere Anzeigenkandidaten mit einer kontextbezogenen Antwort senden. So wird überprüft, ob bei mehreren herausgefilterten Anzeigen weiterhin andere Anzeigen ausgeliefert werden. Anzeigenkandidaten können priorisiert werden, sodass einige Anzeigen als Ersatzanzeigen bereitgestellt werden.

Da die Ausführung zeitgebunden ist, sollten Anzeigenkandidaten entsprechend ihrer Wahrscheinlichkeit ausgewählt werden, eine Auktion zu gewinnen und nicht herausgefiltert zu werden.

Beschränkungen

Folgende Einschränkungen des Frequency Capping für Protected Audience sind bekannt:

  1. Das Frequency Capping für Protected Audience erfolgt auf der Ebene des Geräte-Nutzerprofils. Es gibt keine gemeinsamen Zähler auf anderen Geräten und in anderen Profilen. Alle Steigerungen der Anzeigenimpressionen auf anderen Geräten müssen bei Bedarf manuell berücksichtigt werden.
  2. Gerätezähler werden auf dem Gerät gespeichert und abgerufen. Serverseitige Zähler müssen separat verwaltet werden.
  3. Da Frequency Capping und die zugehörige Anzeigenfilterung auf einem Gerät verarbeitet werden, haben AdTech-Plattformen keine direkte Kontrolle über diese Vorgänge. Um den Grenzwert für die Häufigkeitsbegrenzung des Geräts zu umgehen, können Anzeigentechnologieplattformen mehrere infrage kommende Anzeigen mit unterschiedlichen Filtern senden.
  4. Gebotsanpassungen basierend auf der erfassten Häufigkeit werden nicht unterstützt. Die Funktionen generateBid können keine Häufigkeitszähler sehen.