Include Switzerland in Consent Mode regions from ~July 31st, 2024. about site-kit-wp

[techanvil]

IB ✅, nice one @nfmohit!

[techanvil]

Thanks @kelvinballoo and @nfmohit.

Nahid, to answer your questions:

I felt the missing "to" was an overlook in the ACs, and I added it to complete the phrasing. @techanvil (as the AC author) could you confirm if we should remove "to" to match the ACs here, or just update the ACs?

Good spot - it was a mistake in the AC, I had missed the "to" at the end of the sentence in question. The implementation is correct here and I've amended the AC. Sorry for the confusion!

Hmm, good question. I think using the consentModeSwitzerland feature flag to test this should be sufficient here, as that was added for this specific testing purpose. Since it uses the server time, I don't think there is an easy way to manipulate that. @techanvil Do you have any input on this?

Indeed, the consentModeSwitzerland feature flag was introduced purely to facilitate testing (as per #8643 (comment)) as it's potentially tricky to test the date condition with it relying on the date being set on the server. In this case, we can rely on CR for validation of the date logic.

That said, it would be a good idea to follow up on/after July 31st to re-verify this issue without enabling the feature flag. @kelvinballoo, would you be happy to add an event in your calendar to do this?

[kelvinballoo]

QA Update ✅

Thanks @techanvil , @nfmohit , our implementation is good to go!
I've put a calendar event for me to verify the cut off on 31st July.

Moving this ticket to approval.

[aaemnnosttv]

@techanvil how about we use date-based behavior to implement this sooner than later? I think the tricky part is that we don't use the reference date on the backend, so we might want to think about how to best do this.

Regarding the language, the changes you've suggested look fine to me although I'm wondering if we ever discussed the possibility of referencing them in a more future-proof fashion before, such as "EU consent policy regions" or something like that? This way this language wouldn't need to change, although it's probably unlikely that it will change again 🤔

[techanvil]

@aaemnnosttv we could use the system date on the backend as the condition for this change. As you've pointed out we don't have the concept of a reference date on the backend so it would not be very testable.

It would be nice to implement the reference date on the backend, but it does need some careful consideration, may be fairly non-trivial, and I am not sure this issue really calls for it. I would be more inclined to wrap this in a feature flag that we can then enable on the given date. Or, of course we could take a more simplistic approach with a release-based change, if I have the dates correct we are due a release on the 29th July so we could consider delaying that for a couple of days.

On balance though I think a feature flag would strike the right balance - we could then test it ahead of time, flip the switch on a date of our choosing, or even simply remove the feature flag in the aforementioned release.

I'm wondering if we ever discussed the possibility of referencing them in a more future-proof fashion before, such as "EU consent policy regions" or something like that? This way this language wouldn't need to change, although it's probably unlikely that it will change again 🤔

I think the general direction we've taken has been not to try to overly future-proof it, because we do have longer term plans to allow the regions to be customisable, at which point we'll need to change the copy anyway.

We could consider taking the approach you've suggested, although it would introduce an extra level of indirection, I think we'd need to include a link to the policy alongside the copy for people to be able to understand it properly, and the messaging itself would be a bit less direct. I would be inclined to keep it simple and direct for now, plainly stating the countries that are affected. But maybe a mention of the policy would be the right thing to do here. It might be worth checking in with Andrey and/or Sigal on this one, WDYT?

[aaemnnosttv]

On balance though I think a feature flag would strike the right balance - we could then test it ahead of time, flip the switch on a date of our choosing, or even simply remove the feature flag in the aforementioned release.

That sounds good to me but just let's use it just for testing. The logic could be essentially, flag-enabled OR date on/after July 31. That way we can turn it on manually to test and folks will get it automatically on the right date without us needing to coordinate a remote change. Then the flag can be removed any time after that date.

But maybe a mention of the policy would be the right thing to do here. It might be worth checking in with Andrey and/or Sigal on this one, WDYT?

I think it's worth linking to the policy here but we can address that in a separate issue with the right input from those mentioned.

[techanvil]

Thanks @aaemnnosttv, SGTM.

I've updated the AC here to specify using the date or a new feature flag in the relevant condition.

I've specified that we should use UTC midnight to make the switch, although we could of course choose to honour the server's timezone (it seems to me a more coordinated switch would be appropriate here).

I've also created a separate issue, #8655, where we can consider future proofing the copy and/or including an additional link to the policy (or our support document). Please see what you think - it might be worth resolving this issue first so we can simplify #8655 before opening it up for wider feedback.

[aaemnnosttv]

Thanks @techanvil !

AC ✅

[kelvinballoo]

QA Update ⚠️

This is working well overall. Here are the test results:

With feature flag consentModeSwitzerland on:

• The front-end page source includes CH in the consent mode snippet (tested on both site kit dashboard and an FE page):

  

• When disabling the consent mode, the copy includes Switzerland accordingly:

  When Ads conversion tracking is detected:

  When Ads conversion tracking is not detected:
  

With feature flag consentModeSwitzerland off

• The front-end page source does not include CH anymore in the consent mode snippet (tested on both site kit dashboard and an FE page):

  

• When disabling the consent mode, the copy excludes Switzerland accordingly:

  When Ads conversion tracking is detected:

  When Ads conversion tracking is detected:
  

That said, I do have a few queries below:

QUERIES:
Query 1:
Currently the AC states that when Ads conversion tracking is not detected the copy should be:
Disabling consent mode may affect your ability in the European Economic Area, the UK and Switzerland:
Note that there is no 'to' at the end. However, our implementation has ' to' at the end:

Now, to me, the current implementation is what is right because that's how it is in Production.
That said, I still want to flag it to confirm.

Query 2:
Given that there are some considerations on timing (From 00:00 on July 31st, 2024 (UTC)), is it worth doing any testing around this @nfmohit ?

[nfmohit]

Thank you for sharing your observations, @kelvinballoo!

Query 1: Currently the AC states that when Ads conversion tracking is not detected the copy should be: Disabling consent mode may affect your ability in the European Economic Area, the UK and Switzerland: Note that there is no 'to' at the end. However, our implementation has ' to' at the end:

Now, to me, the current implementation is what is right because that's how it is in Production. That said, I still want to flag it to confirm.

I felt the missing "to" was an overlook in the ACs, and I added it to complete the phrasing. @techanvil (as the AC author) could you confirm if we should remove "to" to match the ACs here, or just update the ACs?

Query 2:
Given that there are some considerations on timing (From 00:00 on July 31st, 2024 (UTC)), is it worth doing any testing around this @nfmohit ?

Hmm, good question. I think using the consentModeSwitzerland feature flag to test this should be sufficient here, as that was added for this specific testing purpose. Since it uses the server time, I don't think there is an easy way to manipulate that. @techanvil Do you have any input on this?

Thank you!

[nfmohit]

Thank you for the confirmation, @techanvil. I hope that answers your queries, @kelvinballoo, please let me know if you have any additional questions. Thanks!