130.71 KB, image/png
128.91 KB, image/png
39 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
44 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
For consideration for an upcoming sprint: There are several email relationship opt-in forms that are passing through blank fields for "Source_URL". All incoming signups should have the URL of the form from which they opt-ed in - both for tracking & reporting, as well as makings sure we have a concrete record of when/how/where/why a user opt-ed into a relationship with us. We need to audit the email signup forms/entry points to figure out the signup form sources that aren't passing through Source URLs, and fix them so that they do. Some known signup forms that don't pass through: https://viewsourceconf.org/berlin-2016/
I've audited the forms on www.mozilla.org and they all seem to be in compliance. If you know of forms on other sites like the one you mention on viewsourceconf.org then we should start filing bugs for those sites. For viewsourceconf.org specifically I believe they use Github for issue tracking. It's possible that we could attemt to grab the "referrer" header in basket when a subscribe call is sent with no "source_url" data, but that is likely to be a bit dirty and might not be all that useful. We could always try and see though. It would only possibly work for sites that call to basket directly, like advocacy.mozilla.org, but wouldn't help View Source as it is proxied through bedrock. But do let us know what priority this is so that we can figure out to how much effort we're willing to go to try to get more of this info outside of just filing bugs for every Mozilla-owned form we can find.  https://github.com/mdn/viewsourceconf/issues
If we can do some more systematic exploratory work (vs. me trying to find every/all signup forms that exist everywhere to test them and see if the Source URL passes through) in this next sprint or 2, that would be good. It's a priority for our team to ensure that we're in the clear legally with documenting where/how exactly we achieved the opt-in. It's not a legal requirement everywhere - but in some countries yes, so we should make every effort to make sure new incoming signups have Source URLs documented. Next step idea: Andrew, could you run a report in SFDC to see how many subscribers in Q3 (since July 1) were added with a blank Source URL? That might help us assess how big of an issue it is at present (vs. the historical #).
(In reply to Jessilyn Davis from comment #2) > If we can do some more systematic exploratory work (vs. me trying to find > every/all signup forms that exist everywhere to test them and see if the > Source URL passes through) in this next sprint or 2, that would be good. > > It's a priority for our team to ensure that we're in the clear legally with > documenting where/how exactly we achieved the opt-in. It's not a legal > requirement everywhere - but in some countries yes, so we should make every > effort to make sure new incoming signups have Source URLs documented. > > Next step idea: > > Andrew, could you run a report in SFDC to see how many subscribers in Q3 > (since July 1) were added with a blank Source URL? > > That might help us assess how big of an issue it is at present (vs. the > historical #). Hey Jess- Is there a next step here for the www durable team? Or we'll know more after Andrew/DEG runs the report? Do you have a general idea what the other sources of sign-ups are? Thx, Jen
(In reply to Jennifer Bertsch [:jbertsch] from comment #3) > Hey Jess- > > Is there a next step here for the www durable team? If there's more investigation work on where/how signup forms exist and if they're passing through Source URL, that would be helpful to see compiled in a doc. > Or we'll know more after Andrew/DEG runs the report? We will know more about the current status of blank source URLS after the report. This in combo with any more investigation work will help us understand the lay of the land and what we need to do to fix. > Do you have a general idea what the other sources of sign-ups are? Ish - it mostly lives in my head and has been documented years ago (but needs updating). https://wiki.mozilla.org/Engagement/User_Engagement/email/newsletters We have this to officially tackle in Q3 Sprint 5 (20 Sep 2016-05 Oct 2016) https://tree.taiga.io/project/jessilyndavis-lifecycle-marketing/task/288 > > Thx, > Jen
Hi All, Ran a report which pulls: Subscriber = True OptedIn = True SourceURL = Blank Created = Current Qtr We have intro'd over 220K Contacts with Blank Source URL's this Quarter. I will be attaching the screen shot of the report. We also intro'd about the same num of Contacts (with) a Source URL, so about half of our Contact records are coming in blank. Link to report in SFDC: https://na48.salesforce.com/00O0B000002Eo0S
Thank you, Andrew! Is there a way to consolidate the Source URLs != clear into groupings of top URLs where these signups are coming in? That'll give us a starting point of knowing which signup forms *are* properly passing through the Source URL and help narrow down signup source URLs that aren't accounted for. Moz.org team - can you help do more investigation on your end this sprint?
(In reply to Jessilyn Davis from comment #8) > Moz.org team - can you help do more investigation on your end this sprint? We've audited all of the forms on mozilla.org and they're all behaving properly as far as we can tell. There's not much we can do outside of the site we control. That said, I will work on a patch to basket and bedrock that will capture the referrer header if a request comes in without a source_url. That might help, but it won't be as good as tracking down the forms that aren't sending the info. We do have the option of returning an error when source_url is missing, but I think gathering whatever info we can is better than rejecting a partial entry.
Created attachment 8784393 [details] [review] PR for basket to record the referrer if no source_url is passed in.
Created attachment 8784399 [details] [review] Link to Github pull-request: https://github.com/mozilla/bedrock/pull/4300 PR to add referrer collection to the bedrock newsletter subscription endpoint
Commits pushed to master at https://github.com/mozmar/basket https://github.com/mozmar/basket/commit/58282b0d06f122b522b73bb1d4443e1050871fcd Bug 1291359: Record referrer on subscribe if no source_url https://github.com/mozmar/basket/commit/7dc9e97dabbcc626fe8a7c0709c4ad8f730229d9 Merge pull request #6 from pmac/record-referrer Bug 1291359: Record referrer on subscribe if no source_url
Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/8810bfa547f37d115890936ffa63d0e29b3a61cb Bug 1291359: Use referrer if no source_url for newsletters https://github.com/mozilla/bedrock/commit/31689f95f70d9b681f2acd6d215b888b379878fe Merge pull request #4300 from pmac/newsletter-use-referrer-no-source-url Bug 1291359: Use referrer if no source_url for newsletters
Hey pmac! This patch went live Aug 25. Since Aug 25, we've had 250k blank source URLs that are coming in from Basket. Going to schedule a mtg to come up with plan for tracking down these blanks - and solving them.
Look like the patch to bedrock went live Aug 30. So maybe check again to see how many since Aug 31 just to be sure.
Coolio - looks like it's closer to 200k then.
Solved with: Bug 1313696