Frequency Capping bei Protected Audience

Frequency Capping ist eine Werbepraxis, bei der die Anzahl der Anzeigen einer bestimmten Kategorie begrenzt wird, die einem Nutzer innerhalb eines bestimmten Zeitraums präsentiert werden. Mit Frequency Capping wird die Nutzerfreundlichkeit verbessert, weil die Anzeigenimpressionen immer aktuell und interessant bleiben. Außerdem können Werbetreibende ihre Werbeausgaben einfacher verwalten.

In diesem Vorschlag wird vorgestellt, wie Protected Audience auf Android verwendet werden kann, um die Frequency Capping-Funktion auf genaue und datenschutzfreundliche Weise zu implementieren.

Protected Audience implementiert Frequency Capping durch eine Kombination aus zwei Funktionen: der On-Device-Speicherung von Zählern für anzeigenspezifische Ereignisse und der Möglichkeit, Anzeigen gemäß einem vordefinierten Satz von Filterstrategien zu filtern. Mit Frequency Capping können Werbetreibende einen Zählergrenzwert über eine Summe von Histogrammwerten für einen bestimmten Zeitraum angeben.

Zähler sind für jede Kombination aus Geräteprofil, Anzeigentechnologie und Zählerschlüssel eindeutig. Jede Anzeige sollte eine Reihe von Zählerschlüsseln enthalten, die verwendet werden, wenn ein Aufruf oder eine Impression für die Anzeige registriert wird. Protected Audience speichert für jeden Schlüssel eine Reihe von Zählern und jeder Zähler zählt alle anzeigenspezifischen Ereignisse, die innerhalb eines bestimmten Zeitintervalls auftreten. Die On-Device-Zähler werden erhöht, wenn eine Impression oder ein Aufruf erfolgt, und die Zählerdaten werden auf dem Gerät gespeichert. Die genaue Persistenzzeit wird später definiert.

Die Anzeigenfilterungslogik im Workflow zur 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 derzeit kein Mechanismus zum Filtern von kontextbezogenen, nicht Protected Audience-Anzeigen implementiert. Dieses Angebot deckt nur den Support auf Käuferseite ab. Falls Nachfrage vorhanden ist, werden wir den Sell-Side-Support zu einem späteren Zeitpunkt hinzufügen.

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

  • Filtern in Echtzeit 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 Anzeigen-ID
  • Funktioniert in allen Apps auf einem bestimmten Gerätenutzerprofil.
  • Korrekte und vollständige Zähler
  • Unterstützung benutzerdefinierter Definitionen von Anzeigenereignissen wie Aufrufe oder Impressionen
  • Eine Funktion für Remarketing- und kontextbezogene Anzeigen.

So richten Sie Frequency Capping ein:

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

Kontextbezogene und Remarketing-Anzeigen weisen auf relevante Histogrammzähler hin, die im Fall einer Ansicht oder Impression aktualisiert werden müssen. 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 nicht von Protected Audience geparst wird.

Das folgende Beispiel zeigt das Datenformat für das Feld adsData in AdSelectionConfig. Beim Remarketing entspricht das Format der Anzeigenliste für eine bestimmte benutzerdefinierte Zielgruppe dem Inhalt des Felds ads, wie im folgenden Beispiel zu sehen:

'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

Anzeigentechnologie-Anbieter können die Methode updateAdCounterHistogram aufrufen, um das Eintreten von Ereignissen zu registrieren, die für das Frequency Capping verwendet werden. Für Schlüssel, die in der eventType der erfolgreichen Anzeige angegeben sind, kann für dasselbe Ereignis wiederholt eine Methode aufgerufen werden.

void updateAdCounterHistogram(@EventType eventType, long adSelectionId)

Eingaben:

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

Mit dem Aufruf updateAdCounterHistogram 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 wurden, oder der kontextbezogenen Anzeigen, die im AdSelectionConfig-Parameter für selectAds enthalten sind.

Wenn Sie davon ausgehen, dass die Anzeige in Schritt 1 den Zuschlag für eine AdSelection mit einem id-Wert von 9999 hat, werden durch einen Aufruf von updateAdCounterHistogram(FrequencyCapFilters.AD_EVENT_TYPE_VIEW, adSelectionId: 999) die Zähler für die folgenden drei Primärschlüssel inkrementiert:

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

Der Name der Anzeigentechnologie stammt aus dem Käuferfeld, entweder aus kontextbezogenen Anzeigen oder aus benutzerdefinierten Zielgruppen, je nachdem, woher die erfolgreichen Anzeigen stammen.

Protected Audience for Android erhöht automatisch 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. Funktional gesehen entspricht dies 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

Zum Erzielen einer optimalen Leistung wird die Filterfunktion für das Frequency Capping innerhalb von AdServices ausgeführt. Protected Audience weiß anhand des Filterfelds im AdsData-Objekt, ob eine Nachricht gefiltert werden muss. In frequency_cap ist eine Liste von Filtern angegeben. Mit den Werten für den Schlüssel event_type und interval_in_seconds wird ein Histogramm der Ereignisse abgerufen, die zum Filtern und Protected Audience verwendet werden.

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

Bei kontextbezogenen Anzeigen mit Frequency Capping-Filtern werden Anzeigen über das Anzeigenfeld im AdSelectionConfig-Objekt übergeben. Anzeigen werden herausgefiltert und als Ergebnis des selectAds-Aufrufs wird die Anzeige mit dem höchsten Gebot zurückgegeben.

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

Das folgende Beispiel zeigt eine Nachricht mit Frequency Capping-Filter:

{
  '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 über erfolgreiche Anzeigen erstellen

Nach Abschluss der Anzeigenauswahl wird ein AdSelectionOutcome-Objekt zurückgegeben, das renderUri und adSelectionId enthält, eine numerische Kennung für den selectAds-Aufruf. Mit dieser ID kann die reportImpression API aufgerufen werden, die derzeit Berichte auf Ereignisebene unterstützt. In der Betaversion 1 unterstützt diese Methode die Berichterstellung für Remarketing-Anzeigen und wird in einer späteren Version auf die Unterstützung der Berichterstellung für kontextbezogene Anzeigen erweitert. Bei kontextbezogenen Anzeigen muss der Käufer angeben, wo die Funktion reportWin während eines reportImpression-Aufrufs abgerufen werden kann. Dazu wird in der Anzeigenstruktur ein zusätzliches Feld namens reportingJS verwendet (siehe Beispiel oben).

Best Practices für die Auswahl von Anzeigenkandidaten

Protected Audience verlagert die Erzwingung des Frequency Cappings vom Server auf das Gerät. Auch wenn erfolgreiche Gebote mit der Privacy Sandbox erfasst werden, wissen Entwickler nicht, warum eine Anzeige nicht ausgeliefert wird. Anzeigen werden aufgrund eines nicht erhaltenen Gebots oder aufgrund von Frequency Capping möglicherweise nicht ausgeliefert. Da es keine vollständige Übersicht über die Gründe gibt, warum bestimmte Anzeigen nicht erfolgreich sind, erfordern Gebotssysteme zusätzliche Maßnahmen, damit die Anzeigen optimal ausgeliefert werden. Diese Best Practices tragen zu einer optimalen Anzeigenbereitstellung mit Protected Audience bei.

Ausreichend Remarketing-Anzeigen senden

Remarketing-Anzeigen können nicht für jeden Nutzer optimiert werden. Wenn ein Nutzer eine große Anzahl von Anzeigen einer benutzerdefinierten Zielgruppe sieht und die Anzeigenlimits niedrig sind, werden möglicherweise alle Anzeigen herausgefiltert. Remarketing-Anzeigen werden regelmäßig aktualisiert, sodass genügend Anzeigeninventar das Frequency Capping durchlaufen sollte, damit Remarketing-Anzeigen weiterhin ausgeliefert werden. Dies muss mit Einschränkungen bei der Größe der Anzeigen ausgeglichen werden, die während des joinCustomAudience-Aufrufs und während der täglichen Aktualisierung der benutzerdefinierten Zielgruppe festgelegt werden können. Käufer müssen berücksichtigen, dass die Latenz während der Gebotsphase unter Umständen höher ist. Um die Auswirkungen dieser Probleme zu minimieren, wird vor dem Aufruf von generateBid nach Frequency Capping gefiltert.

Kontextzähler auf dem Server belassen

Mit der serverseitigen Schätzung kann ein Entwickler grobe Schätzungen dafür erstellen, wann das Frequency Capping aktiviert sein kann. Diese Schätzungen können darauf hinweisen, dass eine Anzeige wahrscheinlich den Grenzwert für das Frequency Capping erreicht hat und daher mit mehr Anzeigenkandidaten gesendet oder vollständig entfernt werden sollte.

Mehrere Anzeigenkandidaten in der kontextbezogenen Antwort senden

Sie sollten vor einer Protected Audience-Auktion mehrere Anzeigenkandidaten mit einer kontextbezogenen Antwort senden. So wird sichergestellt, dass auch nach dem Herausfiltern mehrerer Anzeigen andere Anzeigen weiterhin zu sehen sind. Anzeigenkandidaten können priorisiert werden, sodass einige Anzeigen als Ersatz bereitgestellt werden.

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

Beschränkungen

Folgende Einschränkungen sind beim Frequency Capping der Protected Audience API bekannt:

  1. Das Frequency Capping der Protected Audience API wird auf der Profilebene des jeweiligen Gerätenutzers ausgeführt, es gibt keine gemeinsamen Zähler auf anderen Geräten und in anderen Profilen. Alle inkrementellen Anzeigen, die auf anderen Geräten ausgeliefert werden, müssen bei Bedarf manuell eingebunden werden.
  2. Gerätezähler werden auf dem Gerät gespeichert und abgerufen. Serverseitige Zähler müssen separat verwaltet werden.
  3. Da das Frequency Capping und die zugehörige Anzeigenfilterung auf einem Gerät verarbeitet werden, haben Anzeigentechnologie-Plattformen keine direkte Kontrolle über diese Vorgänge. Um den Grenzwert für das Frequency Capping des Geräts zu umgehen, können Anzeigentechnologie-Plattformen mehrere mögliche Anzeigen mit unterschiedlichen Filtern senden.
  4. Gebotsanpassungen, die auf der aufgezeichneten Häufigkeit basieren, werden nicht unterstützt. Mit den generateBid-Funktionen können keine Frequenzzähler aufgerufen werden.