Closed slightlyoffbeat closed 2 years ago
I wrote to legal to ask for guidance on copy for the banner. I will take what is provided, and send to studio team for user-facing copy.
Here are the options that I can think of for banner/modal behavior:
@alexgibson @pmac for visibility. Any options I'm missing?
@alexgibson could you add technical tasks to the checklist?
Reference docs:
Dev server for the microservice should be available by the end of Monday 28 Feb.
@slightlyoffbeat I added some techincal tasks to the list here, thanks.
As soon as we have a dev server to post data to, I should be able to start working on the flow for this (even if we don't yet have the banner figured out).
Small update:
Thanks @alexgibson. An update from our weekly affiliate meeting:
We decided to move ahead with the option to have a banner that allows users to opt out. A user is opted in unless they click a button on the banner to opt out.
This approach is approved by legal and all stakeholders.
I created a brief to get design & copy from the studio. My expectation is that it will be a very simple banner at the top of the page with copy + button/s.
We decided to move ahead with the option to have a banner that allows users to opt out. A user is opted in unless they click a button on the banner to opt out.
@slightlyoffbeat @birdsarah question on the above:
If the banner at the top of the page is opt-out, then I'm assuming it's not going to block the page content from loading or initiating the CJ event tracking flow. If that assumption is correct, then when someone does click to "opt-out", are there any new / extra flow steps required to remove their data? From prior conversations it was my understanding that we would not initiate the flow until consent was given.
You should be unblocked: https://dev.cjms.nonprod.cloudops.mozgcp.net/aic
If that assumption is correct, then when someone does click to "opt-out", are there any new / extra flow steps required to remove their data?
To make the "opt-out" work, you will need to trigger a new call to the fxa metrics API to get a new flow_id. By doing that and NOT sending it to the cjms endpoint then cjms will have no knowledge of the new flow_id and so will be out of the cjms flow.
You could clean out the cookie or whatever you want to do on your end. But from a preventing join perspective the only necessary step is to get a new flow_id and put it on the subscribe buttons.
@birdsarah I'm hitting a CORS error when trying to POST to the CJMS endpoint locally.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://dev.cjms.nonprod.cloudops.mozgcp.net/aic. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 405.
Can you please see if we can add the following allowed origins to the dev and prod servers? Thanks
Dev:
Prod:
I have pushed a fix for the CORS issue and been able to verify it locally against https://dev.cjms.nonprod.cloudops.mozgcp.net/aic.
In case you need a reference, the specifics are here.
@birdsarah here's my WIP branch up on demo. This is still in a state of flux, but I have the main API flow working for both POST
and PUT
and setting the affiliate marketing cookie.
https://www-demo1.allizom.org/en-US/products/vpn/?cjevent=09d8676b716a11ec831e01500a18050e
~Note: I haven't started on the cookie banner or opt-out mechanism yet, this is next on my list.~
@slightlyoffbeat until we have the opt-out banner finialised I've put together a placeholder banner using Protocol's notification component. It occurs to me that this might actually be usable, as opposed to needing to reinvent things. I guess it depends on how much copy we'll need to display. Thoughts?
Some open questions I'm not sure on the answer to:
Checked with legal: no privacy policy changes needed. We already have a section that covers this.
Unless we receive additional guidance, i'd say we set the cookie for 4 weeks.
Homepage only (english, french & german)
@alexgibson I like the idea of using an existing component and not inventing or reinventing anything. Normally this would be a quick question to UX but we don't have a UX resource currently. I put this option in front of the studio team and will have an answer by end of week.
Homepage only (english, french & german)
Thanks, I'll limit the flow to en
, de
, fr
.
@birdsarah @slightlyoffbeat another open question:
If someone revisits the page later (without a CJ event param in the URL), but already has a marketing cookie set because they didn't opt-out originally, then do we want to show the banner to them again on their repeat visit?
I'll be interested in what @birdsarah says, but I'd say we show the banner.
@alexgibson also, we have a thumbs up to just use the notification component. Copy will come next week.
Good question. I don't know. Lets discuss at next affiliate meeting.
@slightlyoffbeat any update on status of the strings for the banner?
Final copy on cookie banner is now in place:
Demo: https://www-demo1.allizom.org/en-US/products/vpn/?cjevent=09d8676b716a11ec831e01500a18050e
Description
We will soon have the ability to have affiliate links for VPN. This requires changes/additions to Mozilla.org.
When a user arrives to the VPN landing page from an affiliate link, we will show this user a message. This message allows users to either opt in or out of our ability to affiliate attribution.
Tasks include:
fxa-product-button.js
to support overwriting flow params.