Segment_Investigation.md

Segment Investigation

Initial Investigation

Introduction

• The Segment libraries (“ Sources ”) generate messages about what’s happening in a web or native app, and send them to the Segment servers
• Segment then translates the content of those messages into different formats for use by other tools (which we call ‘ Destinations ’), and sends the translated messages to those tools.

Suggested Tracking Process

1. Define Business Objectives
2. Decide what to collect
3. Create naming conventions
4. Develop a Tracking Plan
5. Plan for destination tools

Tracking Plan

PUBLIC TEMPLATE Segment Tracking Plan (RPP) - Google Sheets

[image:8DB45EAB-8345-40FB-A74E-FEA8E740715F-798-00000279841BB0AE/0EA4D0D9-C68E-4E16-B1F9-44C3CDA4ED51.png]

Supported Destination Methods

• MixPanel & AppsFlyer both support track, page, identify, group and alias methods
• Google Analytics only supports track, page, identify methods

Segment Spec

• The Segment Spec provides guidance on meaningful data to capture, and the best format for it, across all of Segment’s libraries and APIs.
• Segment offers a shortcut mobile spec - The native Mobile Spec is a common blueprint for the mobile user lifecycle. The Spec outlines the most important events for mobile apps to track, and automatically collects many of these events when the Segment Android and iOS SDKs are used . Benefits of the native mobile spec , the Native Mobile Spec directly.

Environments

• For developing and testing, standard process is to create and use separate sources for each environment (production, development, staging, etc.) to prevent testing and development activities from filling production systems with invalid data.
• Environments can be given labels on creation, and it is strongly suggested that these labels are used to sort sources

Write key

• The write key is the unique identifier for a source which tells Segment which source data comes from, to which workspace it belongs, and which destinations should receive the data.

Tracking Actions

• The track method is how Segment knows about the actions the users are performing in the app. Every action triggers what is called an “event”, which can also have associated properties. More here => track method reference .
• Default tracked actions - Application Installed, Application Updated and Application Opened.
• The track function can send events back to Segment’s

Adding Destinations

• Simply add in the destinations tab in the workspace
• Configure destination with tracking ID or API Key

---

iOS Setup

https://segment.com/docs/getting-started/02-simple-install/

• Install the SDK using cocoapods
• Add the dependency to the pod file
• Configure SDK in the application delegate
• Identify the currently logged in user using the SDK’s identity call
  • name
  • traits (other known characteristics)

---

Destinations

Mixpanel

• Push notifications:
  • Push notifications are only available for projects bundling the Segment-Mixpanel SDK.
  • In-app notifications are only available for projects either bundling the Segment-Mixpanel SDK or using the client-side Web integration. We have to set-up in-app notification handlers by calling into native Mixpanel methods.
  • For services that send push notifications, read => create a Push SSL certificate following these steps . Then configure the application delegate with the appropriate write key.

Further Investigation

• Method compatibility issues with google analytics (no groups, alias support). Mixpanel / appsflyer are fine.
• No source compatibility issues.
• Cloud mode - you basically send raw interaction data to segment servers which then carry out translation - keeps page size, method count and load time small.
  • is recommended by segment - out of the box functionality like retries, timeouts, delays, privacy blocking, filtering etc…
  • Is the default mode for all mobile sources
• Device mode - extra code on mobile device that allows segment to make calls to destination tool API on your behalf. Data is sent to segment’s server async (probably for logging consistency)

Mode Evaluations

• Use device mode if destinations record information directly on the user’s device. These tools might lose functionality if they aren't loaded directly on the device
• Mixpanel - if cloud mode is used specifically - you will get data on reporting and people but can’t use native features for in-app surveys or auto-tracking - unless you possibly bundle the native sdk and use device mode
• Segment does not encourage device-mode destinations - for app size constraints - blog post on how app size reduces install (dubious - user's need?)
• Many destinations support rich features beyond data collection in their native mobile SDKs. In these cases, segment offers Device-mode SDKs so that information can be collected on the device using Segment, but still get the destination’s complete native functionality.
• Some features that usually require a Device-mode include automatic A/B testing; displaying user surveys, live chat or in-app notifications; touch/hover heatmapping; and accessing rich device data such as CPU usage, network data, or raised exceptions.
  • This is an important consideration for Mixpanel. Push notifications can only be accessed from the native SDK or around a Segment wrapper.

Important Considerations

• App size (212kb + other SDKs)
• Is device mode an un-necessary abstraction?
• Github Open issue (#45) - mixpanel 3.4.x sdk crashes on ios13 (fixed), but not updated in segment-ios-integration repo
• Looks like segment records our users’ IP addresses and then stores them in S3 - do we need to anonymize them or can we use them for targeting later on?

Decision Tree