Include Switzerland in Consent Mode regions from ~July 31st, 2024.

[techanvil]

Feature Description

Google's EU user consent policy is going to be updated to apply to Switzerland along with countries in the EEA and the United Kingdom. This change will take effect on July 31st, 2024. For reference see the preview of the policy update:

From July 31, 2024 Google is expanding the scope of our EU User Consent Policy to apply to users in Switzerland. You can preview the updated policy below. Publishers and advertisers can find more information in the Help with the EU user consent policy page.

https://business.safety.google/ch-euucp-update/

We should ensure Site Kit's default list of regions that Consent Mode is applied to is updated to include Switzerland on or as near to this date as possible.

We should also ensure that the existing copy referring to the EEA and United Kingdom is updated to include Switzerland too. In practice that means the CoMo disconnection confirmation modal's copy should be updated:

Modal when Ads conversion tracking is detected:

Modal when Ads conversion tracking is not detected:

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• From 00:00 on July 31st, 2024 (UTC), or if a new consentModeSwitzerland feature flag is enabled (to facilitate testing):
  • Site Kit's default list of regions that Consent Mode is applied should include Switzerland in addition to EEA countries and the UK.
  • The copy in the Consent Mode disconnection confirmation modal copy should be updated as follows.
    • When Ads conversion tracking is detected:
      • Disabling consent mode may affect your ability to track these in the European Economic Area, the UK and Switzerland:
    • When Ads conversion tracking is not detected:
      • Disabling consent mode may affect your ability in the European Economic Area, the UK and Switzerland:
  • Note how the copy is aligned with that of the proposed update to the EU user consent policy which describes users "in the European Economic Area, the UK and Switzerland".

Implementation Brief

• In feature-flags.json:
  • Add a new consentModeSwitzerland feature flag.
• In includes/Core/Consent_Mode/Regions.php:
  • Instead of having the array of regions in a constant, let's create a new public (static) method, say get_regions, that returns the array.
    • This is because a constant cannot be changed once declared, and we want to conditionally add Switzerland to this array.
    • Replace all usages of Regions::EU_USER_CONSENT_POLICY with the new get_regions method.
  • In the get_regions method:
    • Check if the current date is on or after July 31 2024. This can be done by comparing the value of time() with the strtotime value of 2024-07-31.
    • If the current date is on or after July 31 2024, OR, if the consentModeSwitzerland feature flag is enabled, add Switzerland (CH) to the EU_USER_CONSENT_POLICY array.
  • In assets/js/components/consent-mode/ConfirmDisableConsentModeDialog.js:
    • If the consentModeSwitzerland feature flag is enabled, or CH is included in the list of consent mode regions (available in the regions property of the object returned by core/site getConsentModeSettings selector), update the subtitle variable according to the ACs.

Test Coverage

• In tests/e2e/specs/front-end/consent-mode.test.js:
  • Add test cases with the consentModeSwitzerland feature flag enabled and ensure that the datalayer region property includes CH.
• Add assets/js/components/consent-mode/ConfirmDisableConsentModeDialog.test.js:
  • Add test cases verifying the change of the subtitle with the consentModeSwitzerland feature flag on and off.
• Fix any other failing test.

QA Brief

• Set up Site Kit.
• Turn on the consentModeSwitzerland feature flag using the tester plugin.
• Turn on Consent Mode from SK settings.
• View front-end page source and notice the list of regions set in the consent mode snippet. Verify that the list includes CH.
• Turn off the consentModeSwitzerland feature flag and verify that CH no longer exists in this list.
• Turn consentModeSwitzerland feature flag back on and try to disable consent mode.
• In the opened confirmation dialog, verify that the subtitle is according to the ACs.

Changelog entry

• Include Switzerland in Consent Mode regions from July 31st, 2024, to match the corresponding changes to the EU user consent policy.

[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, https://github.com/google/site-kit-wp/issues/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 ✅

[techanvil]

IB :white_check_mark:, nice one @nfmohit!

[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!

[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 https://github.com/google/site-kit-wp/issues/8643#issuecomment-2091147025) 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?

[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!

[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.