Send geolocation in POST request to IDAPI newsletter signups from frontend

[rBangay]

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 (

frontend/common/app/controllers/EmailSignupController.scala

Line 63 in 7c79867

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.

[jeffjones-product]

I confirmed with Emily that state level location info (US / Australia) is desirable for localised personalisation in future.