Options:

1. iOS changes looking for utm_source in campaign urls to wmf_source instead.
2. iOS instead sends the campaign id value instead of parsing the URL, to match Android
3. iOS and Android both send the value that would be in wmf_source in the campaign url, but instead of parsing the url, we put it in a new separate banner_id field in the campaign config, to avoid this situation in the future.

My (totally unbiased) preference would be option 2: use the id value from the existing campaign structure.
This may add a bit of complexity to analytics, since the id might not be exactly the same as wmf_source, but would be much simpler for us.

@Cstone

iOS parses out the utm_source query item value from our campaign config url data. This value looks something like app_2024_JP_iOS_control, which we then send along to the submitPayment endpoint under the banner request body key. We also send this value to some of our MEP metrics that @SNowick_WMF
analyzes.

This method of parsing the url is brittle (see Slack description thread). Android instead sends the config's id value, which looks something like JP_2024_05. Would you be opposed to iOS using this value to match Android? I wanted to check with you first since this changes what we're sending under banner to the submitPayment endpoint.

Once @Tsevener and @Dbrant make a decision we can move this potentially to tracking

@Tsevener hey sorry this got lost as we were at our offsite last week.

@JMando would the change in utm_source mentioned above still work with your reporting. I think we would just have to know the shortened data is equivalent to the longer string we would get from the non app banners?

Change #1051225 had a related patch set uploaded (by Cstone; author: Cstone):

[mediawiki/extensions/DonationInterface@master] WIP: Switch utm_ to wmf_

https://gerrit.wikimedia.org/r/1051225

@Cstone This should be fine for reporting, so long as

• The utm_medium stays 'WikipediaApp'
• The utm_campaign stays either 'iOS' or 'Android'
• The banner name still comes through in the banner column of civicrm_contribution_tracking
• the utm_source still has 'app' or 'inapp' to denote whether it is native app payment or not

@Cstone @JMando

To be clear, I'm only talking about changing a banner parameter we send to the submitPayment endpoint for native payments. Any payments made through our in-app web view will remain unchanged.

Here's an example of what a submitPayment call from our recent Spanish campaign would look like using the new logic:
POST https://payments.wikimedia.org/api.php
Body:
{"format": "json"
"country": "ES"
"email": "email@email.com"
"payment_network": "Visa"
"full_name": "First Last"
"payment_method": "applepay"
"postal_code": "nnnnn-nnnn"
"recurring": "0"
"amount": "2"
"opt_in": "0"
"action": "submitPayment"
"pay_the_fee": "0"
"city": "CityName"
"first_name": "First"
"last_name": "Last"
"banner": "ES_2024_06"
"app_version": "7.5.4.0"
"language": "en"
"currency": "EUR"
"street_address": "123 Street Name"
"state_province": "NN"
"payment_token": "{token}"
"donor_country": "United States"}

This is a change from what our current app version sends in the banner parameter which is app_2024_ES_iOS_control for this Spanish campaign example.

Let me know if this change sounds okay to you all. Thanks!

@Cstone @JMando

Update from previous comment: Ideally we would also like to prepend the campaign config asset language and platform to the banner ID as well. So in my previous example we would send something like enES_2024_06_iOS, meaning they saw the "en" messaging for the campaign ID ES_2024_06 (link to config for reference), on iOS. Let us know if this will work, thanks!

Update: Per @Cstone banner parameter can accept whatever format we want (there's nothing hardcoded on the backend that assumes the app_2024_$countryCode_$platform;_control format), so we will go with @SNowick_WMF 's preference and use the enES_2024_06_iOS format (see T352717 for more details). That will free iOS up from parsing out utm_source from the config, then @Pcoombe will be able to switch those config url params back to wmf_.

We will update this ticket once the client-side changes are released.

Note: if this is picked up, @SNowick_WMF would need to revisit queries and update.

dbrant opened https://github.com/wikimedia/apps-android-wikipedia/pull/4946

Updated the task title to reflect the actual change that is being made in the iOS app.

cooltey closed https://github.com/wikimedia/apps-android-wikipedia/pull/4946

mazevedofs closed https://github.com/wikimedia/wikipedia-ios/pull/4963

Testing notes for iOS: regression on the regular Apple Pay flow, make sure it works as expected.

Apple pay flow appears to be working on 7.5.9 (4078)

ApplePay working well for me too!