Les champs d'attribution permettent aux appelants d'API de spécifier une liste de chaînes lors de l'enregistrement de la source et des déclencheurs, qui peuvent être utilisées pour le filtrage avant l'attribution. Cela permet un filtrage plus précis pour améliorer l'efficacité des API et offrir plus de flexibilité. Par exemple, il permet de suivre distinctement les annonceurs sur le même site. Il permet également de suivre plusieurs campagnes ou produits dans une même bannière publicitaire.
Les champs d'attribution sont des champs facultatifs qui peuvent être définis lors de l'enregistrement de la source et des déclencheurs. Lors de l'attribution, seules les sources dont les valeurs de champ d'attribution contiennent au moins l'une des valeurs de champ d'attribution du déclencheur seront prises en compte. Si aucune portée n'est spécifiée dans le déclencheur, toutes les sources sont prises en compte. Avant de continuer, vous devez connaître l'API Attribution Reporting et les filtres de niveau supérieur.
Lors de l'enregistrement de la source
Un paramètre facultatif attribution_scopes est ajouté à l'en-tête Attribution-Reporting-Register-Source, qui contient deux paramètres obligatoires : "values" et "limit", et un paramètre facultatif : "max_event_states".
- limit : représente le nombre total de champs d'application distincts autorisés par destination pour l'origine de création de rapports source. Toutes les sources enregistrées existantes ayant la même origine et la même destination de création de rapports, mais une limite inférieure, seront supprimées.
- values : représente la liste des champs d'attribution pour une source spécifique. Ces valeurs doivent être des chaînes de 50 caractères maximum.
- max_event_states (facultatif) : représente le nombre maximal d'états d'événement qu'un appelant d'API prévoit d'utiliser pour tous les enregistrements de sources d'événements ultérieurs. Notez que toutes les sources enregistrées existantes ayant le même point de départ et la même destination pour les rapports, mais un
max_event_states valuedifférent, seront supprimées. La valeur par défaut de ce champ facultatif est 3.
Exemple d'enregistrement de la source
Attribution-Reporting-Register-source: {
//optional
"attribution_scopes":{
"limit": <int>,
"values": <list of strings>,
// optional
"max_event_states": <int>
},
...
}
Lors de l'enregistrement du déclencheur
Un paramètre facultatif attribution_scopes est ajouté à l'en-tête Attribution-Reporting-Register-Trigger lors de l'enregistrement du déclencheur. Assurez-vous que la valeur du paramètre est une liste de chaînes représentant les champs d'application du déclencheur. Le déclencheur ne correspondra qu'aux sources dont le paramètre de valeurs attribution_scopes contient au moins l'un des attribution_scopes du déclencheur, le cas échéant.
Exemple d'enregistrement de déclencheur
Attribution-Reporting-Register-Trigger: {
//optional
"attribution_scopes": <list of strings>,
...
}
Exemple de portées d'attribution
L'exemple suivant montre le cas où un déclencheur est attribué à une source lorsque des champs d'attribution sont utilisés.
Enregistrement de la source 1
Attribution-Reporting-Register-source: {
"destination": "https://trigger.example",
"attribution_scopes": {
"limit": 2,
"values": ["advertiser1"],
"max_event_states": 3
},
...
}
Enregistrement de la source 2
Attribution-Reporting-Register-source: {
"destination": "https://trigger.example",
"attribution_scopes": {
"limit": 2,
"values": ["advertiser2"],
"max_event_states": 3
},
...
}
Enregistrement du déclencheur
Attribution-Reporting-Register-Trigger: {
"attribution_scopes": ["advertiser1"],
...
}
Lors de l'enregistrement du déclencheur, l'API sélectionne les sources à prendre en compte pour l'attribution dont les valeurs de attribution_scopes se chevauchent avec celles de l'enregistrement du déclencheur. Les enregistrements de sources correspondants continueront avec le reste du flux d'attribution. Dans cet exemple, l'appelant de l'API recevra un rapport d'attribution attribuant l'enregistrement du déclencheur au premier enregistrement de la source.
Portées d'attribution par rapport aux filtres
Bien que les fonctionnalités des portées et des filtres d'attribution puissent sembler similaires, le facteur distinctif est l'endroit où ils sont appliqués dans le flux d'enregistrement du déclencheur. Le filtrage des champs d'attribution a lieu avant l'attribution. Cela réduit le pool de sources candidates non expirées ayant le même site de destination et la même origine de création de rapports, en fonction des sources dont les champs d'application se chevauchent avec ceux trouvés dans le déclencheur. Toutefois, les filtres de niveau supérieur sont appliqués une fois qu'un déclencheur a été attribué à une seule source. Si les filtres de la source et du déclencheur ne se chevauchent pas, aucun rapport n'est généré.
L'image suivante montre un groupe de sources et un déclencheur qui ont le même site de destination et la même origine de création de rapports, et qui n'ont pas expiré. Nous allons brièvement expliquer comment les champs d'application et les filtres d'attribution sont utilisés, et si un rapport sera généré en fonction des sources et des déclencheurs disponibles.
Avant l'attribution
- La source 1 est filtrée, car son champ d'attribution ne correspond pas au champ d'application du déclencheur (
casualwear). Même si elle présente la priorité la plus élevée parmi toutes les sources disponibles, elle n'est pas épargnée par le filtrage pré-attribution, qui a lieu avant la vérification des priorités. - La source 2 est également filtrée, car elle n'a pas la même portée que le déclencheur. Cette source a également le même filtre que le déclencheur, mais les filtres de haut niveau ne sont appliqués qu'après l'attribution.
Pendant l'attribution
- La source 3 n'est pas sélectionnée pour l'attribution, car elle a une priorité inférieure à celle de la source 4.
- La source 4 est sélectionnée, car elle a une portée d'attribution correspondant au déclencheur et a la priorité la plus élevée. Les filtres de niveau élevé sont appliqués après l'attribution. Ils ne sont donc pas pris en compte lors du processus d'attribution.
Attribution postérieure
- Aucun rapport n'est généré, car les filtres de niveau élevé de la source sélectionnée (source 4) et du déclencheur ne se chevauchent pas.
L'exemple précédent ne génère pas de rapport. Toutefois, si la quatrième source est complètement supprimée :
Pendant l'attribution
- La source 3 est sélectionnée, car elle a une portée d'attribution qui recoupe celle du déclencheur.
Attribution postérieure
- La source 3 n'est pas rejetée, car son filtre recoupe celui du déclencheur. L'attribution passe ensuite par les autres vérifications post-attribution, et un rapport est généré si elle réussit toutes les vérifications.
Les champs d'application d'attribution réduisent le nombre de sources prises en compte pour l'attribution. Les étapes d'attribution restantes sont ensuite appliquées à ce plus petit ensemble de sources, ce qui peut générer un rapport.
Place des portées d'attribution dans le flux d'attribution
Les champs d'attribution sont appliqués avant qu'une source ne soit sélectionnée pour l'attribution. Cela précède également les filtres de niveau supérieur et le filtrage de la fenêtre de rapport personnalisé. Le diagramme suivant présente une version simplifiée du flux d'attribution global, avec la portée de l'attribution avant l'attribution et le reste des vérifications d'attribution.
Opérations du flux d'attribution
Voici un récapitulatif des différentes opérations effectuées lors du flux d'attribution :
- Enregistrement de la source : lorsqu'un utilisateur interagit avec une annonce sur le site de l'annonceur, un événement de source est enregistré. L'appareil envoie ensuite une requête au point de terminaison de l'origine des rapports, qui répond avec un en-tête contenant les données d'événement source.
- Enregistrement du déclencheur : lorsqu'une conversion se produit sur le site de l'annonceur, un événement déclencheur est enregistré. Une autre requête est envoyée par l'appareil à l'origine des rapports, qui répond avec un en-tête contenant des données d'événement de déclencheur.
- Correspondance de la source : l'appareil associe les événements source et de déclencheur en fonction de critères tels que le site de destination, l'origine des rapports et l'expiration.
- Vérification des champs d'attribution : les sources sont filtrées en fonction de l'intersection entre les valeurs des champs "source" et "attribution_scopes" du déclencheur.
- Attribution : si plusieurs sources correspondent, l'appareil sélectionne la source ayant la priorité la plus élevée pour l'attribution. Si les priorités sont égales, la plus récente est sélectionnée.
- Vérification des filtres : l'appareil compare les filtres de la source et du déclencheur pour déterminer s'ils correspondent. Si les filtres ne correspondent pas, l'attribution est supprimée.
- Désactivation d'autres sources : si les filtres de la source choisie correspondent, l'appareil désactive les sources mises en correspondance lors de l'étape de mise en correspondance de la source. Les sources désactivées incluront celles dont les champs d'attribution ne correspondent pas aux champs de déclencheur.
- Vérifications post-attribution : l'appareil effectue d'autres vérifications sur l'attribution sélectionnée, par exemple pour vérifier si la source est entachée de faux rapports, pour vérifier les attributions en double à l'aide de clés de déduplication, pour vérifier si le déclencheur se situe dans la période de création des rapports de la source et pour vérifier les limites de débit.
- Génération de rapports : si toutes les vérifications sont réussies, l'appareil génère et planifie l'envoi d'un rapport d'attribution au point de terminaison de l'origine des rapports.
Étapes suivantes
- Pour en savoir plus sur les champs d'attribution, consultez la présentation du filtrage pré-attribution sur GitHub.
- Pour en savoir plus sur les filtres, consultez Définir des règles client à l'aide de filtres.