-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Venmo with FPTI Analytics Events #846
Conversation
braintreeClient.getConfiguration((configuration, error) -> { | ||
if (configuration == null && error != null) { | ||
callback.onVenmoPaymentAuthRequest(new VenmoPaymentAuthRequest.Failure(error)); | ||
braintreeClient.sendAnalyticsEvent("pay-with-venmo.app-switch.failed"); | ||
braintreeClient.sendAnalyticsEvent(VenmoAnalytics.TOKENIZE_FAILED.event); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We used "app-switch" failed more previously, but to be more accurate, I updated this to only be "app switch failed" for errors returned from actual app switching, or if Venmo is not installed.
@@ -110,7 +111,7 @@ public void createPaymentAuthRequest(@NonNull final FragmentActivity activity, | |||
callback.onVenmoPaymentAuthRequest(new VenmoPaymentAuthRequest.Failure(new BraintreeException( | |||
"Cannot collect customer data when ECD is disabled. Enable this feature " + | |||
"in the Control Panel to collect this data."))); | |||
braintreeClient.sendAnalyticsEvent("pay-with-venmo.app-switch.failed"); | |||
braintreeClient.sendAnalyticsEvent(VenmoAnalytics.TOKENIZE_FAILED.event); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
braintreeClient.sendAnalyticsEvent(VenmoAnalytics.TOKENIZE_FAILED.event); | |
braintreeClient.sendAnalyticsEvent(VenmoAnalytics.TOKENIZE_FAILED); |
nit: Would it be better to convert VenmoAnalytics.TOKENIZE_FAILED
to a String
and remove the .event
property access?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could rename the "event" property in this enum, or what you're describing sounds like a class with a companion object filled with string constants rather than an enum - do you think that would be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'd go companion const val
to reduce some of the boilerplate. If we were performing a switch / when
on it i'd keep it an enum, but for braintreeClient.sendAnalyticsEvent()
a plain string value is equally sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool - updated 👍
@@ -110,7 +111,7 @@ public void createPaymentAuthRequest(@NonNull final FragmentActivity activity, | |||
callback.onVenmoPaymentAuthRequest(new VenmoPaymentAuthRequest.Failure(new BraintreeException( | |||
"Cannot collect customer data when ECD is disabled. Enable this feature " + | |||
"in the Control Panel to collect this data."))); | |||
braintreeClient.sendAnalyticsEvent("pay-with-venmo.app-switch.failed"); | |||
braintreeClient.sendAnalyticsEvent(VenmoAnalytics.TOKENIZE_FAILED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On BT iOS (and PPCP Android & iOS) we moved to this "notify pattern" (see BT iOS & PPCP Android examples) for firing analytics. The goal is that each analytics string constant should only be referenced in 1 place in source code.
The purpose was to reduce errors in our firing of the events, since we have previous SDK version with bugs for forgetting to send analytics in certain cases. This way we know that every time we return a callback result/cancel/error to the merchant, we're firing the right event (and only once).
What do you think of this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's a good idea - except for Android since we have two different callbacks for the two different parts of the flow, we'd need 5 analytics helper methods (one success, and then a cancel and failure for each callback) - do you still think that would be helpful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, to make sure we always fire an analytics event with each completion callback, I think it makes sense even if it requires 5 methods
private void callbackPaymentAuthAppSwitchFailure(VenmoPaymentAuthRequestCallback callback, VenmoPaymentAuthRequest request) { | ||
braintreeClient.sendAnalyticsEvent(VenmoAnalytics.APP_SWITCH_FAILED); | ||
callback.onVenmoPaymentAuthRequest(request); | ||
} | ||
|
||
private void callbackPaymentAuthFailure(VenmoPaymentAuthRequestCallback callback, VenmoPaymentAuthRequest request) { | ||
braintreeClient.sendAnalyticsEvent(VenmoAnalytics.TOKENIZE_FAILED); | ||
callback.onVenmoPaymentAuthRequest(request); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the app switch fails, I think we want that to count as a holistic "tokenize_failed", right? For that case on iOS we did this, and send both a "conversion" event (tokenize_failed) + the "extra details" event (app_switch_failed).
This way we can use the "conversion" event of tokenize_failed to capture all failures, to use to measure against the total # of "start" events.
Though we went back and forth a few times on this with iOS, so definitely down to talk through this and come up with a pattern that makes sense across both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok agreed I think that makes sense - updated the app switch failure to send both the conversion analytic event and the app switch failure one. I agree with that approach for all the events 👍
@@ -77,19 +76,6 @@ public void showVenmoInGooglePlayStore_opensVenmoAppStoreURL() { | |||
"https://play.google.com/store/apps/details?id=com.venmo"); | |||
} | |||
|
|||
@Test | |||
public void showVenmoInGooglePlayStore_sendsAnalyticsEvent() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we removing this unit test ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the switch to FPTI analytics we trimmed down some of the extraneous analytics events not related to conversion metrics. This analytics event is no longer being sent, and we test the actual functionality of this method in a separate unit test, so removed this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Should we consider removing this line of code in VenmoClient Line 60?
braintreeClient.sendAnalyticsEvent("android.pay-with-venmo.app-store.invoked");
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes good catch! That was meant to be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wild - this same event slipped through the cracks on iOS too (see code snippet). So we actually are still sending it on iOS v6.
Do we think this is a useful event? Should we add it to our events doc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc: @jaxdesmarais
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed and confirmed we will leave this event out for now 👍
Summary of changes
Checklist
[ ] Added a changelog entryAuthors