Adding registration_location & registration_location_state to Newsletter Guest Account Creation.
Work has already been done in IDAPI to accept the new registrationLocation and registrationLocationState fields (https://github.com/guardian/identity/pull/2881). UPDATE: only some of the IDAPI endpoints have been setup to accepts these new fields, work is underway to make the /consent-signup and /consent-email endpoints accepts them.
Impact
MRR/CRM
The CRM teams for the different regions cannot personalise marketing based on region for users without a registration_location set.
Currently the US has a workaround in which these ‘regionless’ users are counted as US users if they have signed up for a US editorial newsletter but this could result in false positives and a poor CRM experience.
Advertising
Once these users complete their accounts and sign in, emails without a registration_location cannot be used for email matching (hashed emails matched by a third party for personalised advertising on-page), limiting ad revenue.
work involved
For any newsletters forms that are rendered in dotcom-rendering or make use of the /email endpoint in frontend then the work can be done in frontend (
|
def submit(form: EmailForm)(implicit request: Request[AnyContent]): Future[WSResponse] = { |
)
in conjunction with the creation of a new state header passed through from fastly (https://github.com/guardian/fastly-edge-cache/blob/2286dec1345ee02632eabcf70ee81250adc05f86/theguardiancom/src/main/resources/varnish21/geo.vcl#L26-L50)
TODO (in another card)
Locate any newsletter forms that do not conform to the 'work involved' criteria above. Perhaps there are newsletter forms elsewhere that call the IDAPI endpoint directly.
Adding registration_location & registration_location_state to Newsletter Guest Account Creation.
Work has already been done in IDAPI to accept the new
registrationLocationandregistrationLocationStatefields (https://github.com/guardian/identity/pull/2881). UPDATE: only some of the IDAPI endpoints have been setup to accepts these new fields, work is underway to make the /consent-signup and /consent-email endpoints accepts them.Impact
MRR/CRM
The CRM teams for the different regions cannot personalise marketing based on region for users without a registration_location set.
Currently the US has a workaround in which these ‘regionless’ users are counted as US users if they have signed up for a US editorial newsletter but this could result in false positives and a poor CRM experience.
Advertising
Once these users complete their accounts and sign in, emails without a registration_location cannot be used for email matching (hashed emails matched by a third party for personalised advertising on-page), limiting ad revenue.
work involved
For any newsletters forms that are rendered in
dotcom-renderingor make use of the /email endpoint infrontendthen the work can be done infrontend(frontend/common/app/controllers/EmailSignupController.scala
Line 63 in 7c79867
in conjunction with the creation of a new state header passed through from fastly (https://github.com/guardian/fastly-edge-cache/blob/2286dec1345ee02632eabcf70ee81250adc05f86/theguardiancom/src/main/resources/varnish21/geo.vcl#L26-L50)TODO (in another card)
Locate any newsletter forms that do not conform to the 'work involved' criteria above. Perhaps there are newsletter forms elsewhere that call the IDAPI endpoint directly.