Distinguishing unintentional clicks from intentional ones

[alois-bissuel]

Hello,

In some circumstances, people may click on ads without wanting to do so. This can be the case, for example on mobile devices, where an ad is clicked while the user just wanted to close it. Some sites may also use shady patterns to drive clicks, like showing ads on top of content in an unexpected way.

While those unintentional clicks may lead to higher CPMs, they do not lead to any advertiser value and produce a frustrating user experience, i.e. being sent to a site the user does not wish to go to.
Therefore, distinguishing between “normal” and unintentional clicks is required for managing campaigns. Based on that distinction, this may lead to:

• reviewing the design of an ad
• stop displaying ads on certain sites
• for a DSP, not billing an advertiser for a certain number of clicks (when a CPC billing model is in place)

The usual practices to determine whether a click is likely to be intentional or not are:

1. Looking at the coordinates of the click on the ads. On mobile, clicks that are located in the top right corner of an ad are likely to be attempts at closing the ad, rather than navigating to the advertiser site.
2. Looking at the sequence of events following the user landing on the advertiser site. Does the user immediately leaves the site? Or do they browse several pages? In that respect, the analysis is usually done on the number of events and the type of events (e.g. category view, product view, sale…) following the click within a certain timeframe.

Based on this data, a hierarchy of click “quality” can be defined. This hierarchy would typically have a max of 3 to 4 levels, from the “likely intentional click” to the “likely unintentional click”.
An entity managing a campaign would need reporting across this classification on:

• The clicks volume and costs (per domain, device type…)
• Attribution (per domain, device type…)

Note: we’d like to highlight that events of the advertiser site following a click are used here for two distinct purposes:

• Setting the “click quality”. Any type of event (landing on the advertiser site, browsing product pages…) can usually be used for that.
• Do attribution per se, i.e. linking a conversion (sale) to a click. Typical events used for that are sales.

To the best of your knowledge, qualifying clicks based on events on the advertiser site has not been discussed previously.

On the technical side, a new header could be added to the API to signify that a trigger event should be used to qualify the click. As a final word, the tentative worklet-based aggregation key generation may enable this use case, but only for the aggregate API.

[csharrison]

Hey @alois-bissuel , thanks for the issue. I want to make sure I crisply understand the proposal.

1. Do you expect that "click quality" will need to be a signal to alter the attribution algorithm? For instance, a bad click signal could delete the source event from browser storage if it was poor quality.
2. If (1) is not in scope, do you see this as being just a means of adding metadata to subsequent trigger registrations? If so, can you explain why something like a partitioned cookie could not be used to achieve this (to store click information for future registrations on the advertiser domain).

Maybe it would help to explain why you think the worklet design could enable this use-case, but our existing declarative design wouldn't?

[alois-bissuel]

Hello @csharrison ,
Sorry for the very late answer.

1. Yes. For instance we give precedence to "good click" over "bad clicks" coming after it as long as the former is still within the attribution window. This means that we attribute to the best possible click within the attribution window.
2. It could be also done this way, but I fail to see how first-party data could be used here. My current mental model of the Privacy Sandbox is that there is no way to know where the user on the advertiser's site came from (ie an organic visit or a click on an ad), hence the inability to use the solution 2. Maybe my mental model needs an update there!

Please forget about my comment on the worklet design. I think it only uses information from pairs of (source, trigger) to create the histogram key and value and has no state.

[csharrison]

1. Yes. For instance we give precedence to "good click" over "bad clicks" coming after it as long as the former is still within the attribution window. This means that we attribute to the best possible click within the attribution window.

I see, in that sense the click quality acts sort of similar to the existing priority system for source registration, only it can be mutated after the fact with cross-site signals.

2. It could be also done this way, but I fail to see how first-party data could be used here. My current mental model of the Privacy Sandbox is that there is no way to know where the user on the advertiser's site came from (ie an organic visit or a click on an ad), hence the inability to use the solution 2. Maybe my mental model needs an update there!

I was thinking of storing something like the "sequence of events following the user landing on the advertiser", so that subsequent conversions would be modified based on this sequence (e.g. was it a "good" or "bad" sequence). But yes it would be difficult within the PS target privacy threat model to join this with cross-site information like click coordinates, etc.

---

At a high level, this use-case makes sense to me, but it seems complicated enough that we might want to add it to the meeting agenda to discuss in more detail. Some things I still have questions about:

1. How does click quality form a hierarchy? I understand some kind of spectrum but why is a hierarchy needed?
2. Maybe related to the previous question, but are quality signals "linear"? e.g. could you imaging implementing this via one-shot mutations to a previous source's priority on every event in a sequence, without taking into account the entire sequence at once?
3. How critical to the use-case is a quality signal that combines click-time data with an advertiser event sequence? Do you think the two types of signals could be treated independently?
4. Could an API as simple as "delete my previous source targeting this destination" satisfy the core use-case here, or do you think fine-tuning something like the most recent source's priority is needed?