Send analytic events for in-person eligibility verification / enrollment

[angela-tran]

The implementation details still need to be fleshed out, but the acceptance criteria below seem correct based on dev workshop discussion on 2024-09-11.

Acceptance Criteria

• As part of in-person eligibility verification / enrollment, analytic events are sent for:
  • started eligibility
  • returned eligibility
  • started payment connection started card tokenization
  • closed payment connection ended card tokenization
  • returned enrollment
  • failed access token request
• Analytic events capture if the eligibility verification / enrollment is from an in-person interaction or not

Additional context

[angela-tran]

Something I just thought of: we've talked about a feature for viewing past enrollment records, and one of the columns we're thinking we'd show is "Verified by" which is really only applicable to in-person enrollments. Is this relevant to this ticket at all? I think in general we want analytic data to be anonymized, but then we also talked about backfilling the enrollment records using analytic events and transit processor group enrollment data.

[angela-tran]

@indexing @thekaveman and I discussed the above and decided we don't need to worry about capturing "Verified by" for this ticket or the September release.

[thekaveman]

Let's align the property naming here with what we choose for the field name in #2287

@indexing suggests method for the name of the field/property.

Devs suggest possible values of digital or in_person.

[angela-tran]

Just realized this ticket needs #2244 and #2345 to be done first, so moving this to Blocked

[indexing]

In this interest of more intuitive naming for parameters in our analytics tool, I propose changing method to enrollment_method. The values for this parameter remain as digital and in_person.

[angela-tran]

@lalver1 #2382 has the code in a state that's ready to have analytics added to it. You could either build off that branch or wait for it to be merged into main.