Acoustic has rolled out the custom landing page domain. Example page: https://lp.email.wikimedia.org/wiki. I have confirmed these landing pages meet the security requirements we needed to adhere to when rolling out the click-tracking custom domain (links.email.wikimedia.org).

We need the lp.email record modified to the value I provided (21f8e16b76313de0.acs4.tc.) and the _c02d3189682d060e348d305b652c2ece.email record added.

Following up here regarding the DNS requests I made on Thursday. I believe the timeout for verification on the AWS side is 7 days, so if you can get these in place early this week we'll avoid possibly needing to go through verification process again.

Hi all,

Received, thank you. I have provided the certificate info to Acoustic and will provide an update here when they respond.

I don't have access to the referenced task. Could you please add me or otherwise give me access to the cert?

Hi all,

I noticed that as well, @Pcoombe, when I was using the search test from Google. Looking at the robots.txt syntax, I don't see why it isn't working. I don't see anything that would indicate the root of the site would be disallowed from Googlebot accessing it. I do think Google is ignoring the query strings, but not sure if that's having any effect here.

Confirming that I see the change to robots.txt and that Google is indeed able to crawl the page noted above: https://search.google.com/test/rich-results/result?id=7JM3WeWxIU0EBukJwGLgKw

Looks like the robots meta tag is live. Checking in to see when the robots.txt change will be pushed live. Once that's out, Google should be able to read the description meta tag and show that in the search results.

Noting that there are two other blockers for the meta descriptions showing up in search engine results. #2 and #3 in the original task description:

I'll defer to Peter on how to distinguish between different donation pages from a technical perspective, but from strategy perspective, you would want to be able to customize the meta description on different pages based on the intended target audience. For example, a page shared on social media might have a different description than a page that shows up high in Google search results.

Regarding timing, I would just say as soon as it's ready we'll get it implemented. The 6C email campaign has begun, but there will be gaps within it in which we can ask Acoustic to update the domain for the unsubscribe page.

One more ping on this to see if we can get the cert so it's in place before the 6C email campaign.

Checking in on the status of this certificate. Thank you.

Hello, I am just checking in on the status of this certificate.

@Dwisehaupt - thank you for the DNS update. Here is the CSR that can be used to generate the certificate.

Thank you, @Dwisehaupt, I will send this to Acoustic. Just a reminder that they also need this DNS update made on wikimedia.org:

Just noting that Acoustic has said they plan to update this process to follow the one used for link tracking (links.email.wikimedia.org): they'll manage the cert in Amazon and it will auto-renew. But they have not launched that feature yet and I do think it's worth the branding upgrade to implement this custom domain ASAP.

@Dwisehaupt - I asked about this and Acoustic sent the following response:

Also, for this site Acoustic will generate the CSR files and provide them to Wikimedia so that you can generate the certificate. Could you please complete this CSR questionnaire so they can generate the files? I've gotten it started (bolder answers).

Thanks, @Dwisehaupt. Here's what Acoustic needs added to DNS in order to complete the setup on their end:

Reviving this discussion post-Q2. Let me know if the development request is not clear at this point. I'll reup my suggestion to name this field something more generic that doesn't include "rml" in the name so that it could be used more generally (i.e. tracking a signup on a banner that is not RML related). So, an example URL an email recipient would receive might look like:

Click-tracking for the links.email.wikimedia.org subdomain is available now in Acoustic. Thanks for everyone's help in getting this completed!

From my perspective, this task can be closed unless there are any further questions or comments about the SSL cert for this subdomain.

Noting that the cert for links.email is now in place and all requirements stated in this task are implemented: https://www.ssllabs.com/ssltest/analyze.html?d=links.email.wikimedia.org

Thank you, @ssingh. These changes look good to me and I am asking Acoustic to verify. @DBu-WMF, Brian Sisolak and I will follow up with next steps and testing of the link tracking once Acoustic completes their setup.

@Vgutierrez - Attached are the DNS updates needed to verify the SSL certs. Some will replace the existing CNAMEs. Once these are live, we should be done with the DNS updates for this task.

Thank you, @Vgutierrez. I've alerted Acoustic support that the updates have been made and I will follow up here when they provide next steps.

Regarding DNS updates, I am going to paste the comment I linked to in my last comment below so all of the information is in this phab task:

Hi all,

The DNS updates need to be done by WMF as they are updates for the wikimedia.org domain. The rest of your questions need to be answered by WMF.

Updating this parent task with next steps in order to implement click tracking for Wikimedia on Acoustic because this is not SSL-specific.

Noting on this parent task that Acoustic has confirmed they can meet the requirements detailed in the subtask. More details in my latest comment: https://phabricator.wikimedia.org/T188561#8433505

An update: Acoustic has confirmed they can implement all of the requirements mentioned in this comment on this task. The example click tracking domain - links.e.protectus.org - has been updated to meet these requirements in order to show this in practice and it receives an A+ rating on SSL Labs. For implementing DNS CAA, the CA is Amazon (amazon.com).

Correct, @greg. I'm still gathering feedback from Acoustic's support and will report back here. Hoping to get more information this week.

Yes, he is looped in on the Acoustic support case.

Noting here that I have opened a support case with Acoustic based on the requirements discussed in the subtask (T188561). I will provide specific responses and updates from Acoustic on that task.

Agreed that this will be a long term improvement from an analytics perspective whenever it could be implemented. This would be helpful for tracking the banner where an RML signup came from and other types of signups through banners that might occur in an acquisition program.

Yes, I was proposing adding a new parameter to the URL in that comment. The utm_source value should not change as it's used to tracking donations on those emails. Here is an example of the new URL might look like with the rml_source value added in:

Hi all,

Thanks for the feedback and requirements documentation, @Vgutierrez. Acoustic, the vendor in this case, doesn't have specific documentation regarding this, but I can tell you that they recently moved to certs issued by Amazon AWS. I am going to open a support ticket with Acoustic to see if they can address the specific issues you've noted. First, I wanted to ensure I understand them correctly so I have a couple of clarifying questions:

To provide a little context from the Acoustic side, here is an example link in the current RML email program:

@JMando - I do not believe I have access to the shared file server. We use Google Drive on our end and I have shared a folder there directly with you that you could use to send the data. Or you could share it with me via your Slack org as I am a guest on that account.

Checking in here to see if we could get this data tomorrow (Oct. 11).

Thanks for confirming, @Eileenmcnaughton. Since I do not have Civi access, would it be possible for you to provide me the list of RML email donations with Contact ID, Email address, amount and donation date/time since Sept. 13? The utm_source value for these donations would start with "RML2223_".

Thanks, @Eileenmcnaughton, for noting the documentation. Based on this documentation, it looks like if the record has a Contact ID in Acoustic (née Silverpop) it's rml_source value will not be updated in Civi because the query that makes that update is specifically looking for records in Acoustic without Contact IDs. Is that correct?

@Pcoombe - perhaps we can close this as declined for now? In the U.S., it looks like we're no longer using the <select> element as we've removed State as an input. I also don't see it in the other countries I spot checked.

Circling back to this as I still see the issue in Google search results.

Noting that Acoustic (née Silverpop) now uses SSL Certs hosted by Amazon Web Services and no longer supports weak ciphers. Here is an SSL Labs test of a current Acoustic client SSL cert: https://www.ssllabs.com/ssltest/analyze.html?d=links.e.protectus.org

@jbolorinos-ctr - That happens in current best as well, correct? Just trying to fix the issue with the spacing of the text bubble here.

Background color on top text is corrected now in my proposed banner.

I would propose that we do away with the bubble background on that message. None of the other text is in an inner dark blue bubble any more. Here's a banner with that removed:

Jumping in here to note that this does affect visitors who are not logged in as well. The problem is with the entire top menu rather than just the notifications (see example of the issue with a non-logged in session). That said, I do not have a solution to offer immediately and this only happens when the browser window is very short. Also, it does not obscure content nor limit functionality. I would recommend keeping this open at low priority so it can be resolved when time allows.

Noting that the example domain (links.e.cantwell.com) also receives a score of A on Qualys SSL Labs test.

@jbolorinos-ctr - I have put in a fix which is to mimic the behavior of desktop small and hide the payment methods on the upsell step. The donor can navigate all the way back to the payment/amount step and change that if desired.

@Pcoombe - Take a look at this banner to resolve the issue. It takes the style of disabling the payment method or frequency option depending on selection from CB Mobile Large. I also fixed an issue where the Amazon Pay logo color didn't change to white when selected.

@jbolorinos-ctr - I put in a fix in this banner. Check it out and see if it works as expected for you. @Pcoombe - if this fix passes muster can you port back into the current best?

@jbolorinos-ctr - Do these appear differently than in the control mobile small banner? I agree that they could probably be laid out better, but we would want to keep the layout the same as control for the purpose of this test. Let me know if they are different than control and, if so, I will dig into it.

@jbolorinos-ctr - I believe this issue is resolved. I fixed by changing the display property of this element from table to flex (diff). This should be fine, but please do review the browser screenshots with this change to confirm.

@jbolorinos-ctr - Take a look now. I changed some padding to resolve the issue.

Noting the CSS elements here that are setting the height on this iframe:

Now I'm not receiving any emails?

@EWilfong_WMF - when tagged?

Changed preferences.

@EWilfong_WMF - does this?

Does this generate an email to me?

Btw, a good way to review these frb variables is to set up live expressions in Chrome's inspector tools (Firefox may have something analagous). You can see that I did that with the relevant variables in this screenshot:

I have a proposed solution in this banner.

I'll take a look at this task this week.

I don't think there was a specific test of this change, but it was implemented in part to avoid a possible display issue in some browsers. From an Aug. 1, 2019 comment on the Current Best banner sheet from @spatton:

@jbolorinos-ctr - This is the intended behavior of the banner. I believe the thinking is that once the user clicks "Continue" they've begun the donation process and no longer need the RML. I'll look back and see if there was a test or more notes regarding this decision.

Just wanted to note that we recently discovered that WYDG Foundation webpage is not up-to-date (it uses numbers/text from a previous annual report rather than the most recent one). Might want to hold on any tests that link to that page until that is updated.

@spatton @jbolorinos-ctr - Fixed in this banner and the other two test variants!

Confirming that you fix looks looks good to me in Browserstack testing. And IMO, the slight font weight change on the PTF amount is an UX improvement (maybe one we should test out in 6C).

Easy fix: https://meta.wikimedia.org/w/index.php?title=MediaWiki%3ACentralnotice-template-spatton_trilogy_RMLTiming1_enNL_dsk_lg_CBupdates&type=revision&diff=20284391&oldid=20278311

As another data point, I am able to submit a successful transaction with a valid CC number and expiration data WITHOUT entering a security code using the steps above.

Sounds good. I've updated the RML options banner to include this update: https://en.wikipedia.org/wiki/Wikipedia?banner=Trilogy_mlWW_dsk_p1_lg_RMLTiming1&country=US

Yes, we can auto-focus the email input in the nag. Noting again that this is how it works in control. So, let's fix it there as well.

Agreed with this assessment that the "back" button is unnecessary/confusing on the RML options step in the nag. I've modified the banner to hide that on this step.

I am seeing the email input being auto-selected (put in focus) when the user clicks the RML link. This is the code in this banner and the control:

Just noting on this main task that this is the current candidate being QA'ed: https://en.wikipedia.org/wiki/Wikipedia?banner=Trilogy_mlWW_dsk_p1_lg_RMLTiming1&country=US

We left this as "Submit" to keep it consistent with the control that does not have a second step. The idea being we want the initial signup behavior to be the same even if there is a second step. My concern with changing the language of this button to "Continue" is that it could depress signups if a user infers a drawn out process. I'm certainly open to testing that assumption.

The link in my comment loads for me. Can't think of why it would not load for you unless there's a client-side issue.

Proposed solution in this banner: https://en.wikipedia.org/wiki/Wikipedia?banner=Trilogy_mlWW_dsk_p1_lg_RMLTiming1&country=US. This only changes the behavior of the UI in the main banner, not the nag. The nag UI is different (back instead of close), so I'm not exactly sure how to handle. Thoughts?

I don't believe this is a bug. We can decide if it's a feature we want to implement. Currently, clicking outside of the nag does not close the nag does not close the nag in any banner; adding this would be new functionality.

Confirming that this is still an issue. I do not have a proposed solution yet, but wanted to note that I can recreate it.

Can you give it another pass now, @jbolorinos-ctr? I spent more time ensuring the styles match the mobile large payment buttons. It looks good in my local testing.