Thanks for the background on that.

Hi, @Ejegg--I've started working on this and I noticed that there are some activities for recurring retries. Do you know under what circumstances the Recurring Processor Retry - Start and Recurring Processor Retry - Success activities are / were used?

If we're ultimately going to be pulling data from the SurveyMonkey API, what would you think about using option #2 and making it look somewhat like the data we'd be receiving from the API? I took a quick look (https://api.surveymonkey.com/v3/docs#api-endpoints-get-surveys-survey_id-responses-response_id-) and it looks like it's deeply nested json that could flattened out into something like:

• responses
• questions
• answers

Here's the task: https://app.asana.com/1/3758245663860/project/1210424144163385/task/1214144717663857?focus=true I've added each of you as collaborators.

Thanks, @Ejegg--I'll put in a task in Asana to put together some tracking for this.

Thanks! The number of upgrades for the portal looks much more reasonable now 😆

Gotcha. And are we logging the retry attempts in any way? Or would the only indicator I have that a retry was attempted be that first recurring failure email?

Thanks--so we aren't adding any new communications yet, just changing the retry timing / amount. Is there are good way to distinguish donations eligible for a retry?

Hi, @Ejegg--I don't think there's necessarily a timing consideration (unless you wanted to do an experiment), but it might take some time to build the supporting models to measure improvement, depending on what you're looking for. Who's the best person to get us up to speed on the exact changes we're planning to make and what improvements we'd expect to see as a result of those changes?

Hey, @Ejegg--just a heads up that I'm seeing some more upgrades attributed to the portal that shouldn't be. Could you take a look?

Yep, these look good 👍

Thanks, @Ejegg--would you be able to set the prior activities that were incorrectly set to Is from Donor Portal to no for those that were incorrectly classified as yes? I've re-classified these activities in the data pipelines, but it would be good to be consistent between Metabase and Civi, if possible.

That'd be ideal if we could revise the CiviCRM data, but if it's too much of a hassle, we can come up with something on our end, so just let me know once you all have had more time to think it through.

Thanks for that update. I can make some adjustments to the pipeline to only calculate revenue impact from donor portal activities--that's the main priority right now, though I could definitely see folks asking to track this kind of thing outside of the portal in the future, too.

@Lars--apologies, but I've realized that we don't actually specify the frequency unit on the upgrade / downgrade activities either, though we do have all of the amounts we need.

I should be able to handle de-duplicating the cancellations and attributing them to the portal until we can resolve this issue. For https://phabricator.wikimedia.org/T409097, am I understanding correctly that activities are being created for DR-initiated upgrades/downgrades, but they're not classified in the same way as other upgrades/downgrades?

Thanks, @KHill-WMF--I looked into this a bit more and this is not an isolated occurrence. You can find more activities with this query:

Ahh, I see what you mean. Using the existing labels is fine with me. Thanks for this!

Ah, thanks for confirming--good to know that it looks like these contacts still exist in Civi.

Hi, @Lars I know you've already found some of the issues, but Megan mentioned that it's possible Faircom might have attempted to send mailings to merged contacts? They get a monthly data drop from us, but it's an append and doesn't drop any records.

Super, then I think that's all of activities? I'm not as close to the UI development, but those are all I recall.

@AKanji-WMF @Ejegg Are those the only actions that can be taken in the save flow? What about downgrading?

You mean the URLs would be structured like: /beacon/donor_portal/<cid>/<route>/<recur_id>?wmf_source=xxx? If we are able to track against specific IDs, that would be preferred. Would the log data contain the full URL? If so, we can parse what we need from that as long as we have the full URL and a timestamp (e.g. daily unique users).

Yes, we need all of the activities tracked both from the donor portal and not from the donor portal. This is the distribution of activities I have right now:

Hi, @Lars -- from what I understood, I think that should already be happening? I think it's only the upgrade/downgrade action that's inconsistent right now. That is to say, we do have pause and cancel activities are being logged in Civi that don't occur through the donor portal and we'd assumed that those captured all of those actions that were currently initiated in the UI.

Thanks, @greg -- is it just the link to create an access request in the document? I'm getting a permission denied error when I click on it:

That's great! Thanks so much for this. I've made adjustments to the code to accommodate the doubled activities, as well.

Thanks, I'm already using is_from_donor_portal for the other activities, so I can use that for this activity as well.

Yes, I think so! Quick question, though, how should I interpret the values for:

...native_amount_removed":30.25,"usd_amount_removed":21.89}

Is this just the amount of the monthly contribution X 12 - the new annual recurring amount?

Hi, Dallas--three more users without Superset access requesting to be added to Metabase:

Thanks, Dallas!

Hi, Dallas! I have a couple more users to look into:

Thanks, Dallas!

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILeOcjSMDWaPKv5kSNAQ0MOx5Ve6sgekijKWv8Jmce+e chudson@wikimedia.org

Yubikey public key: cccccbngbnjb