Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Effective 3rd Party In-App Analytics Integrations

Effective 3rd Party In-App Analytics Integrations

In-app analytics are what help your business understand how your apps are being used. All too often, integrating 3rd party analytics tools into your app is done hastily and without the kind of care that your team would take for a user-facing feature or major architectural concern. This can lead to both data issues and code maintainability challenges. Included here is a simple process for planning and implementing 3rd party in-app analytics tools for your apps.

Audrey Troutt

May 01, 2018
Tweet

More Decks by Audrey Troutt

Other Decks in Programming

Transcript

  1. 2 What do I mean by In-App Analytics Tools? •

    Mixpanel • Flurry • Localytics • Swrve • Amplitude • Google Analytics for Firebase • Adobe Marketing Cloud Tools for measuring what users are doing in your app
  2. 3 Why Care about In-App Analytics Implementation? • You don’t

    want to think about analytics all the time • You will have to update/add to it over time • Mistakes have consequences for your business
  3. 4 Why Care about In-App Analytics Implementation? • Happy Developers

    ◦ Cleaner app code ◦ Easy to add/modify/replace tools • Happy Business/Product People ◦ More accurate information ◦ Better product/business decisions
  4. 5 TEST Give yourself and your business partners confidence in

    the data you are providing. Overview PLAN Business/product and engineering need to be on the same page about what will be measured and how it will be measured. DOCUMENT THE PLAN AND IMPLEMENTATION The analytics implementation needs to be documented where both business and engineering can access it in the future. IMPLEMENT Make it easy on future developers (including yourself) by loosely coupling your app with your analytics tools and introducing constants for strings used in analytics measurement. 2 3 4 1
  5. 6 If your product/business partner didn’t tell you what, specifically,

    they need to measure and why, then STOP INTEGRATING and go ask them. 1. Have a Plan IMPORTANT
  6. 7 1. Have a Plan Start by understanding what actions

    your users take that are most closely tied to success/revenue • Move outward from there to significant steps before and after that • Measure more than just your key actions, but don’t try to measure everything Product/business should talk with engineering about what is going to be hard to measure accurately--is it worth it? IF YOU DON’T KNOW WHERE TO START
  7. 8 1. Have a Plan • List people/profile data that

    needs to be tracked/available ◦ Examples: age, gender, order count, card member type, timezone, paid subscriber (true/false) • List each event name, the desired metadata for those events, and when/where you plan to measure ◦ Example: Measure each “social share” event with “social platform” and “content type” metadata AFTER callback for successful content share. • Plan to be consistent with naming across platforms (web, iOS, Android) WHAT TO INCLUDE IN YOUR PLAN
  8. 9 2. Document the Plan Business people AND developers need

    to know what these event names are and what they mean. • A spreadsheet works well or shared wiki • Track *when* data started being collected ◦ Example: Data available since version X.X.X, but “event foo” was first measured in version X.X.Y IT’S KIND OF LIKE A CONTRACT
  9. 10

  10. 11 3. Implement MyAwesomeAnalyticsEvents { Const String EVENT_SOCIAL_SHARE = “Social

    Share” Const String EVENT_PURCHASE = “Purchase” } MyAwesomeAnalyticsProperties { Const String PROPERTY_SOCIAL_PLATFORM = “Social Network” Const String PROPERTY_SHARE_CONTENT_TYPE = “Shared Content Type” Const String PROPERTY_MEMBER_TYPE = “Shared Content Type” } CREATE CONSTANTS
  11. 12 As much as possible, avoid using 3rd party classes/methods

    directly in your app code. Instead, create a wrapper for all initialization, profile updating, and event measurement: 3. Implement CREATE AN ANALYTICS WRAPPER
  12. 14 3. Implement MyAwesomeAnalyticsFacade { initializeAll() { Mixpanel.init(MY_MIXPANEL_KEY, ...) Flurry.initialize(MY_FLURRY_KEY,...)

    } setMemberType(String value) { Mixpanel.setProperty(PROPERTY_MEMBER_TYPE, value) Flurry.setUserProperty(PROPERTY_MEMBER_TYPE, value) } measureSocialShareEvent(Map properties) { Mixpanel.measureEvent(EVENT_SOCIAL_SHARE, ...) Flurry.measureEvent(EVENT_SOCIAL_SHARE, ...) } } CREATE AN ANALYTICS WRAPPER
  13. 15 4. Test • Yes, test just like you’d test

    any other code. ◦ This is best done manually ◦ Use your spreadsheet as a guide • Have a debug/developer account with your analytics provider to keep your prod data clean TEST YOUR IMPLEMENTATION
  14. 16 TEST Give yourself and your business partners confidence in

    the data you are providing. Use your spreadsheet/plan as a testing guide. Summary PLAN Business/product and engineering need to be on the same page about what will be measured and how it will be measured. DOCUMENT THE PLAN AND IMPLEMENTATION The analytics implementation needs to be documented where both business and engineering can access/update it in the future. IMPLEMENT Make it easy on future developers (including yourself) by loosely coupling your app with your analytics tools (make a wrapper/facade) and introducing constants for strings used in analytics measurement. 2 3 4 1