LG-8423 log cancel analytics from barcode page

[svalexander]

🎫 Ticket

Lg-8423

🛠 Summary of changes

Adjusts current analytics event that track user's selection from cancel page after arriving there from the barcode page. Additional information logged in events includes whether the user cancelled their enrollment, service provider and enrollment info.

Updates step name for the barcode page so that it is unique and be used to determine if the extra_analytics_attributes should be included.

idv_cancellation_go_back event logged from the cancellations_controller represents a user who has clicked the no, keep going button and therefore declines to cancel their enrollment.
idv_start_over event logged from the session_controller represents a user who has clicked the Start over button and therefore cancels their enrollment.

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

• Create a new enrollment or use one where you've already become ready to verify
• Click the cancel your barcode button at bottom of "ready to verify page"
• Click the no, keep going button
• Make sure event was logged in events.log and that the value of the cancelled_enrollment field is false, step is barcode and extra attributes are not nil
• Click the cancel your barcode button at bottom of "ready to verify page"
• Click the Start over button
• Make sure event was logged in events.log and that the value of the cancelled_enrollment field is true, step is barcode and extra attributes are not nil

[aduth]

Do we need a separate event for this, or can we use the step and location parameters which should be included with links to the cancellation screen and are logged with the existing cancellation visit event?

I think we need to change the step here to something unique, since it was intended to uniquely identify the source step where users choose to cancel, but "verify" is a different step in the identity verification flow (which is likely causing that step to be overcounted currently).

identity-idp/app/views/idv/in_person/ready_to_verify/show.html.erb

Line 120 in f2c903b

<%= link_to t('in_person_proofing.body.barcode.cancel_link_text'), idv_cancel_path(step: 'verify') %>

[svalexander]

Do we need a separate event for this, or can we use the step and location parameters which should be included with links to the cancellation screen and are logged with the existing cancellation visit event?

I think we need to change the step here to something unique, since it was intended to uniquely identify the source step where users choose to cancel, but "verify" is a different step in the identity verification flow (which is likely causing that step to be overcounted currently).

@aduth We could potentially change the step name in order to distinguish "the ready to verify page"/barcode page and the "verify your info" page. The additional information this event seeks to track though is if a user opts to cancel their enrollment or not, and information about their enrollment. This seems slightly different from the current idv_cancellation_visited event which seems more like a page visitation event rather than information about potentially cancelling an enrollment.

@daviddsilvanava thoughts?

update: Chatted w/ David and we decided to go with modifying the following existing events so they track information about the enrollment and user's action re:cancelling
* IdV: cancellation visited (user got to this pg from 'barcode' step)
* IdV: start over (user got to cancel page AND cancelled)
* IdV: cancellation go back (user got to cancel AND did not cancel)

[aduth]

update: Chatted w/ David and we decided to go with modifying the following existing events so they track information about the enrollment and user's action re:cancelling

• IdV: cancellation visited (user got to this pg from 'barcode' step)
• IdV: start over (user got to cancel page AND cancelled)
• IdV: cancellation go back (user got to cancel AND did not cancel)

Yeah I think that'd be great if we can use the existing events and add any extra details we want specific to IPP.

[aduth]

The way the methods are set up in AnalyticsEvents to receive **extra arguments, it's not necessary to explicitly assign an extra key, we could choose to merge the extra values directly into top-level arguments.

Suggested change

	extra: barcode_step ? extra_analytics_attributes : nil,
	**extra_analytics_attributes,

(This suggestion would require moving barcode_step consideration to extra_analytics_attributes:)

def extra_analytics_attributes
  extra = {}
  if barcode_step?
    extra.merge!(
      cancelled_enrollment: false,
      # ...
    )
  end
  extra
end

[aduth]

Couple minor thoughts:

• If this method returns a boolean value, conventionally I'd expect it to end with ?
• The explicit return isn't necessary since the last statement of the method is implicitly returned

Suggested change

	def barcode_step
	return params[:step] == 'barcode'
	end
	def enrollment
	return InPersonEnrollment.where(user_id: current_user.id).first
	def barcode_step?
	params[:step] == 'barcode'
	end
	def enrollment
	InPersonEnrollment.where(user_id: current_user.id).first

[aduth]

We probably want to add some checks that enrollment exists, since we don't validate that anywhere. For example, I was able to trigger a 500 error by;

1. Sign in
2. Go to http://localhost:3000/verify/cancel?step=barcode
3. Click "No, keep going"

[svalexander]

good catch!

[aduth]

LGTM 👍

[aduth]

Do we need to include this, or can we rely on it being provided in the default event attributes?

identity-idp/app/services/analytics.rb

Line 73 in f226bdd

service_provider: sp,

Suggested change

service_provider: decorated_session.sp_name || APP_NAME,

[svalexander]

you're right, we do get that in the default - i'll remove this addition

[aduth]

Same:

Suggested change

service_provider: decorated_session.sp_name || APP_NAME,

[tomas-nava]

approve!