Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarifying attribution logic when multiple publishers are involved #68

Closed
benjaminsavage opened this issue Sep 18, 2020 · 10 comments
Closed

Comments

@benjaminsavage
Copy link

I have read the proposal a few times, and I am not exactly sure how things work in a situation where there are clicks from multiple publishers prior to a conversion.

So let's take an example. I see an ad on instagram.com for a back-rest. I'm interested. I click on it. I browse the website for a bit then decide to do some more research. I go to Google and search for similar products. I click on a few search results (that happen to be sponsored). Eventually I decide to buy the original one. I do a Google search the original product again, as a means of navigating back to the product. I click the (sponsored) link back to the website. I buy the product. The websites fires a conversion event.

So in this example, there are 2 clicks from publisher websites that both direct to the same destination website. How does this work? My read of the proposal is: "Both instagram.com and google.com will receive an attributed conversion report. The Google one will have an "attribution credit" of 100. The instagram one will have an "attribution credit" of 0. Is this correct?

@benjaminsavage
Copy link
Author

The proposal talks about a "cap" of at most 3 attributed conversion reports being generated per conversion generated. How exactly does this cap work? Is the cap per publisher website? Is the cap across ALL publisher websites? If there are more than 3 click-events which could potentially receive attribution, what is the logic for deciding which three are selected? Is it the 3 most recent across all publishers? How does this interact with the set of pixels installed on the advertiser website?

@benjaminsavage
Copy link
Author

Sorry to spam you with all these questions - I'm splitting them into multiple comments so that you can answer each one separately.

How does this interact with the aggregated reporting API? Is it the same; as in, there is also a cap of 3, and the logic for deciding which 3 is the same, and the conversion will only appear in aggregations for those 3?

@csharrison
Copy link
Collaborator

So in this example, there are 2 clicks from publisher websites that both direct to the same destination website. How does this work? My read of the proposal is: "Both instagram.com and google.com will receive an attributed conversion report. The Google one will have an "attribution credit" of 100. The instagram one will have an "attribution credit" of 0. Is this correct?

Yes that's how attribution works, as long as the reportingorigin is the same for both clicks. If it is different, the two reportingorigins will see just their respective click with 100 credit. See this section which specifies that attribution is scoped to conversiondestination, reportingorigin pairs.

The proposal talks about a "cap" of at most 3 attributed conversion reports being generated per conversion generated. How exactly does this cap work? Is the cap per publisher website? Is the cap across ALL publisher websites? If there are more than 3 click-events which could potentially receive attribution, what is the logic for deciding which three are selected? Is it the 3 most recent across all publishers? How does this interact with the set of pixels installed on the advertiser website?

We support 3 attributed conversion reports per click. I think the scoping of per click makes things easier to understand because the limit should be applied independently for all clicks. Let me know if that doesn't fully answer your q.

How does this interact with the aggregated reporting API? Is it the same; as in, there is also a cap of 3, and the logic for deciding which 3 is the same, and the conversion will only appear in aggregations for those 3?

In our aggregate explainer we say:

The event-level API allows up to 3 conversions per click, and subsequent ones are dropped. It is reasonable to support at least this number in the aggregate API as well.

Ideally we would try to make the logic as similar as possible in the aggregate API to make the results comparable to the event level API. You're right if we went over the cap, we would drop the conversions and they wouldn't appear in aggregations.

@benjaminsavage
Copy link
Author

Thanks for the quick response! I'm glad I asked, I think I had misunderstood the explainer...

OK, so let me see if I understand what you're saying. Let's assume that instagram.com uses a reportingorigin of instagram.com, and google.com uses a reportingorigin of google.com. In that case, are you saying that they are totally, and fully independent? And that no number of clicks from one influences the other?

@csharrison
Copy link
Collaborator

That's right for attribution, though we are considering adding the reporting cooldown which is not keyed by the reporting origin (under a privacy model that assumes implicitly that the reporting origins are colluding). This will limit the total # of conversion reports for a <publisher,advertiser> pair in a given time period. (Note that the reporting cooldowns are not current in Chrome's implementation yet).

@johnivdel FYI

@alexistacquard
Copy link

I have some troubles to understand the use case here,

In the case you are using rule-based attribution models as Last clic, you just want the credit of a conversion to be assigned to one marketing channel, if I am right with the example here, the API is assigning the credit to two marketing channels present into the path to conversion, to Instagram & Google while we are using a last clic attribution models?

@csharrison
Copy link
Collaborator

Yes that's right, the current API scopes the attribution to the configured reporting origin. If there are multiple configured reporting origins they will compute attribution differently. This is potentially non-ideal if you have multiple reporting origins, but we chose this because it felt like an alternative may be abusable e.g. with malicious reporters intentionally triggering the API on non-ad clicks to ruin measurement and take the "last click" slot.

@alexistacquard
Copy link

I have the impression we miw then two different things here:

1/ Attribution with a rule based model should assign the credit of the conversion to one marketing channel. Attribution value is there. With the current system, if you want to manage attribution for two ad tech companies, especially working on performance getting paid on commission, the advertiser will pay two times the same conversion while only one should be paid according the rule based attribution model selected by the advertiser.

2/ Sharing attribution results with ad tech companies should be the choice of the advertiser which I understand it is not anymore the case here and additionnaly use case 1/

@eriktaubeneck
Copy link

A couple clarifying questions, now that there are a few new areas where this might apply:

  1. Will the aggregate attribution reports similarly be scoped to (conversiondestination, reportingorigin) pairs? I.e. source events from two different sites, which use two different reportingorigin won't effect each other?
  2. Now that this proposal is also considering view through, will the 3 source event limit still be global?

cc @csharrison

@csharrison
Copy link
Collaborator

A couple clarifying questions, now that there are a few new areas where this might apply:

  1. Will the aggregate attribution reports similarly be scoped to (conversiondestination, reportingorigin) pairs? I.e. source events from two different sites, which use two different reportingorigin won't effect each other?

Yes, that's correct.

  1. Now that this proposal is also considering view through, will the 3 source event limit still be global?

I think you mean the 3 reports per source event? Those will not be global, they are scoped to the particular source event. However for views, we limit one single report per view.

I'm gonna close out this old issue since the proposal has changed quite a bit. Let's open a new issue if there are remaining questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants