Conversation
Before this change the event was fired even when the screen was being initialized. However, the event should be fired only when the user explicitly updates the filter.
|
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
|
You can test the changes on this Pull Request by downloading the APK here. |
ashiagr
left a comment
There was a problem hiding this comment.
All events are tracked properly, thank you 🙇♀️. Just have two question:
Note: I'm not sure how to reproduce the error screen with "contact support" button, so I haven't tested that flow.
I tested this flow and noticed two tracking event being logged:
I: 🔵 Tracked: jetpack_scan_error_contact_tapped
I: 🔵 Tracked: support_opened, Properties: {"origin":"SCAN_SCREEN_HELP"}
Is this ok?
make sure that the properties for the events match the properties from the "Jetpack Section Tracking Events" doc.
Tracked properties match properties from the "Jetpack Section Tracking Events" doc. I see a comment in the doc
We might want to consider tracking {action:"fix/ignore", cause: "threatsNotFixed/..."} state, as the server returns NOT_FIXED for all threats when the server credentials are missing.
I think it's a good suggestion. Do you plan to track it?
|
Thanks @ashiagr!
Ahh, good point. I'll remove
I'll add it right away :). Since no-one commented on the gdoc I wasn't sure if I should proceed with it. |
# Conflicts: # libs/analytics/WordPressAnalytics/src/main/java/org/wordpress/android/analytics/AnalyticsTracker.java # libs/analytics/WordPressAnalytics/src/main/java/org/wordpress/android/analytics/AnalyticsTrackerNosara.java
ashiagr
left a comment
There was a problem hiding this comment.
LGTM, 👍.
Feel free to merge it after resolving merge conflict.
# Conflicts: # WordPress/src/main/java/org/wordpress/android/ui/jetpack/scan/ScanViewModel.kt
Parent issue #13326
Adds tracking to Jetpack Scan.
jetpack_scan_accessed - fired when the user clicks on "Scan" on MySite screen
jetpack_scan_history_accessed - fired when the user clicks on "History" toolbar action on Scan screen
jetpack_scan_history_filter - fired when the user changes tab on Scan History screen
jetpack_scan_threat_list_item_tapped - fired when the user clicks on a threat on Scan/Scan History screens
jetpack_scan_threat_codeable_estimate_tapped - fired when the user clicks on "GetFreeEstimate" button on threat detail screen
jetpack_scan_run_tapped - fired when the user clicks on "Scan" button on Scan screen
jetpack_scan_ignorethreat_dialogopen - fired when the user clicks on "ignore threat" on Threat detail screen
jetpack_scan_threat_ignore_tapped - fired when the user confirms dialog for "ignore threat" action on Threat detail screen
jetpack_scan_fixthreat_dialogopen - fired when the user clicks on "fix threat" on Threat detail screen
jetpack_scan_threat_fix_tapped - fired when the user confirms dialog for "fix threat" action on Threat detail screen
jetpack_scan_allthreats_open - fired when the user clicks on "fix N" button on Scan screen
jetpack_scan_allthreats_fix_tapped - fired when the user confirms dialog for "fix N" action on Scan screen
jetpack_scan_error_contact_tapped - fired when the user clicks on "contact support" on error screen
jetpack_scan_error - fired when an error screen or snackbar message is shown to the user
To test:
Test that all the above events are being fired. Also make sure that the properties for the events match the properties from the "Jetpack Section Tracking Events" doc.
Note: I'm not sure how to reproduce the error screen with "contact support" button, so I haven't tested that flow.
PR submission checklist:
RELEASE-NOTES.txtif necessary.