DEV Community: Mixpanel

How to add analytics event tracking in SwiftUI (the elegant way)

Mixpanel — Fri, 22 Oct 2021 21:09:42 +0000

This article was written by Joseph Pacheco and originally appeared on Mixpanel's product analytics blog, The Signal.

SwiftUI is groundbreaking in its capacity for enabling well-architected, concisely defined, and highly readable UI code.

So the last thing we want is to step on all of that by needlessly littering our views with event tracking calls to analytics platforms. The solution: Update the elegance of your event tracking approach to match the elegance of SwiftUI.

Here’s how to harness the incredible product insights of an analytics framework like Mixpanel, while keeping your SwiftUI as clean and simple as it was meant to be.

Analytics code can balloon SwiftUI views

Never before in iOS have fewer lines of code been needed to create something like a task list. Rather than a UITableViewController with accompanying storyboard and custom UITableViewCell subclasses, all we need now is a binding to a list of tasks and 10-ish lines of actual code:

struct TaskListView: View {

    @Binding var list: TaskList

    var body: some View {
        NavigationView {
            List(list.tasks) { task in
                TaskRow(task: task)
            }
        }
        .toolbar {
            Button("Add") {
                ...
            }
        }
    }
        ...
}

But what happens if we want to add event tracking to this view? Perhaps we want to track when the Add button is tapped, when the view appears, or even when each task is presented. Suddenly our crisp structure is flooded with verbose tracking code, like this:

struct TaskListView: View {

    @Binding var list: TaskList

    var body: some View {
        NavigationView {
            List(list.tasks) { task in
                TaskRow(task: task)
                    .onAppear {
                        Mixpanel.mainInstance().track(event: "Task List Item Viewed", properties: [
                            "Task Type": task.type,
                            "List Title": list.title,
                            "List Type": list.type,
                                                        ...
                        ])
                    }
            }
                        .toolbar {
                    Button("Add") {
                        Mixpanel.mainInstance().track(event: "Button Tapped", properties: [
                            "Button Name": "Add",
                            "Button Context": "Task List",
                                                ...
                        ])
                                        ...
                    }
                }
            .onAppear {
                Mixpanel.mainInstance().track(event: "Task List Viewed", properties: [
                    "List Title": list.title,
                    "List Type": list.type,
                                        ...
                ])
            }
        }
    }
}

Yuck! All we did was add tracking for three events with 2-3 properties for each event, and our view code is completely visually dominated by those additions.

Sure, we could move the row tracking to the TaskRow view itself, but we’d still be left with an ugly mess. And views often have more than three events!

To clean this up, we’re going to have to take a multi-pronged approach.

Decouple events from analytics platforms

Step one in our battle is making the code we do end up writing in our views less ugly and more elegant.

Analytics platforms, including Mixpanel, often provide a singleton where you can pass an event name as a string, along with properties to track as a dictionary. That’s how we ended up with our event tracking code above.

Mixpanel.mainInstance().track(event: "Button Tapped", properties: [
          "Button Name": "Add",
          "Button Context": "Task List",
                ...
])

But as I explain in this article, there’s a lot of problems with inserting this directly into your views. Aside from being unattractive in context, there is no type safety, and your view code becomes dependent upon third party API that you have zero control over.

So the best thing to do is to decouple your tracked events from all platforms (including Mixpanel), and take full advantage of the power of native Swift structs.

If you follow my guide, the above code could end up looking something like this:

let event = ButtonTapped(name: .add, context: .taskList)
analyticsService.track(event)
Swift
And this looks a heck of a lot better in context:

struct TaskListView: View, AnalyticsTracking {

    @Binding var list: TaskList

        let analyticsService: AnalyticsService

    var body: some View {
        NavigationView {
            List(list.tasks) { task in
                TaskRow(task: task)
                    .onAppear {
                                                let event = TaskRowViewed(taskType: task.type, listTitle: list.title, listType: list.type)
                                                analyticsService.track(event)
                    }
            }
                        .toolbar {
                    Button("Add") {
                        let event = ButtonTapped(name: .add, context: .taskList)
                                        analyticsService.track(event)
                                        ...
                    }
                }
            .onAppear {
                                let event = TaskListViewed(title: list.title, type: list.type)
                analyticsService.track(event)
            }
        }
    }
}

But it’s still not great. Yes, we’re down to two lines of code per event (easily combinable into one). Yes, each of the events is fully native, independent of third-party code, and strongly typed. But the event code still somehow dominates the view more than the view code itself!

And can you imagine if we had to write additional code to derive any of the event properties? The majority of the view would be analytics code!

In an ideal world, each of these calls would be as concise as possible so as to appear hierarchically secondary to the view code (while of course still maintaining readability).

Use custom event initializers to reduce footprint

Right now, our native events are initialized with exactly the data they need to track.

While our above example TaskRowTapped has only three parameters, plenty of events in the real world can end up having a number of parameters that are uncomfortably long in length.

So let’s imagine it with a few more params:

let event = TaskRowTapped(taskCreatedDate: task.created, taskTitle: task.title, taskType: task.type, listTitle: list.title, listType: list.type, ...)
Swift
That’s pretty long. And it would be even worse if we turned it into a single line by wrapping it in the call to the analytics service:

analyticsService.track(TaskRowViewed(taskType: task.type, listTitle: list.title, listType: list.type))

We’d basically have created textual line breaks all over our code.

But, as it turns out, all the information we need for this event is derived from the Task and TaskList objects associated with the view. So we can create a custom init for the TaskRowedViewed event which takes just these two parameters, and derives the others for us, as so:

struct TaskRowTapped: AnalyticsEvent {

    init(task: Task, list: TaskList) {
                self.taskTitle = task.title
        self.taskType = task.type
                self.taskCreatedDate = task.created
        self.listType = list.type
        self.listTitle = list.title
                ...
    }
    ...
}

And just like that, our formerly massive line is a lot more digestible:

analyticsService.track(TaskRowViewed(task: task, list: list))

The goal here is to create custom initializers that take as few parameters as possible (within reason) from which the requisite event properties can be derived.

If the initializer is obviously reusable, add it to the original event definition like we did above. If the initializer is somehow unique to a given view (perhaps because it takes the view model for the view as a parameter) add it in an extension of the event in question and group it with your view.

/// Filename: TaskRowViewed+TaskListViewModel

extension TaskRowViewed {

    init(_ tasklistViewModel: TaskListViewModel) {
        ...
    }
}

Whatever the case, all logic that derives event parameters from models or view models as they are should be done in one of these initializers—not in the view itself.

Use custom view modifiers for more logical grouping

While each line of event tracking code is now vastly more concise, we still haven’t accounted for the fact that we have these lifecycle modifiers all over our code that are used solely to track events for analytics purposes.

I’m talking about all the onAppear {} and onDisappear {} closures that wouldn’t otherwise be there if events weren’t being tracked. They add clutter. And worse, doing this obfuscates the handful of instances where you might be using a lifecycle modifier for logic specific to your app, especially if multiple events were tracked in each closure:

struct TaskListView: View, AnalyticsTracking {

    @Binding var list: TaskList

        let analyticsService: AnalyticsService

    var body: some View {
        NavigationView {
            List(list.tasks) { task in
                TaskRow(task: task)
                    .onAppear {
                                                analyticsService.track(TaskRowViewed(task: task, list: list))
                    }
            }
                .toolbar {
                    Button("Add") {
                        analyticsService.track(ButtonTapped(name: .add, context: .taskList))
                    }
                }
            .onAppear {
                                analyticsService.track(TaskListViewed(list))
                                analyticsService.track(SomeOtherEvent(param: something))
                                analyticsService.track(YetAnotherEvent(param: somethingElse))
            }
                        .onDisappear {
                                analyticsService.track(TaskListClosed(list))
                        }
        }
    }
}

This is not very readable. In fact, it’s pretty stressful to sift through if you’re trying to make sense of what a given view is actually doing.

Wouldn’t it be great if we could group our tracking code together in a logical fashion that doesn’t litter our actual view logic?

struct TaskListView: View, AnalyticsTracking {

    @Binding var list: TaskList

    var body: some View {
        NavigationView {
            List(list.tasks) { task in
                TaskRow(task: task)
                                        .track(/// Trackevent in response to lifecycle event)
            }
                        .track {
                                /// Track a bunch of events for different lifecycle events
                                ...
                        }
                .toolbar {
                    Button("Add") {
                        track(ButtonTapped(name: .add, context: .taskList))
                                        ...
                    }
                }
        }
    }
}

Thanks to custom view modifiers, we can!

We first need to take stock of all the possible lifecycle and user-triggered events that we might respond to:

.onAppear { ... }
.onDisappear { ... }
.onTapGesture { ... }
.onLongPressGesture { ... }
.onDrag { ... }
.onDrop { ... }
...

And we’ll turn those into a nice enum we can easily reference (trust me, it will be worth it):

/// A trigger that causes analytics events to be tracked
enum AnalyticsEventTrigger {
    case onAppear
    case onDisappear
    case onTapGesture
    case onLongPressGesture
        ...
}

Then we create a struct that groups events that will be tracked together in response to a trigger:

/// A group of analytics events tracked together in response to a common trigger
struct AnalyticsEventGroup {

    // MARK: Properties

    /// The trigger causing the analytics events to be tracked
    let trigger: AnalyticsEventTrigger

    /// The events being tracked
    let events: [AnalyticsEvent]

    // MARK: Initializers

    init(_ trigger: AnalyticsEventTrigger, events: [AnalyticsEvent]) {
        self.trigger = trigger
        self.events = events
    } 
}

And then we create a custom struct that conforms to ViewModifier:

/// A view modifier that tracks analytics events
struct AnalyticsEventTrackingModifier: ViewModifier { 
        ...
}

Now this is where the magic happens.

First, we require our modifier be initialized with the event groups we are going to track as well as the analytics service it will use for tracking:

 /// A view modifier that tracks analytics events
struct AnalyticsEventTrackingModifier: ViewModifier {

    // MARK: Private Properties

    /// The analytics service used to track events
    private let service: AnalyticsService

    /// The groups of analytics events to track
    private let groups: [AnalyticsEventGroup]

    // MARK: Lifecycle

        /// Initialize with an analytics service and groups of events to be tracked by the analytics service
    init(service: AnalyticsService, groups: [AnalyticsEventGroup]) {
        self.service = service
        self.groups = groups
    }

        ...
}

Then, in the body of our modifier, we respond to each lifecycle and user-triggered event we want to track in response to, tracking all analytics events in the corresponding group:

/// A view modifier that tracks analytics events
struct AnalyticsEventTrackingModifier: ViewModifier {

        /// The groups of analytics events to track
    private let groups: [AnalyticsEventGroup]

        ...     

        // MARK: Body

    func body(content: Content) -> some View {
        content
            .onAppear {
                trackAll(in: groups.group(for: .onAppear))
            }
            .onDisappear {
                trackAll(in: groups.group(for: .onDisappear))
            }
                        /// Account for additional triggers
                        ...
    }

    // MARK: Helpers

    /// Track all events in the given group
    private func trackAll(in group: AnalyticsEventGroup?) {
        if let group = group {
            group.events.forEach { event in
                service.track(event)
            }
        }
    }
}

Recall that in a view modifier, the content passed into the body represents the view to which you applied the modifier. That’s why we apply onAppear and onDisappear to content in the above code. It’s as if we applied these closures directly to our original view, and adding this here doesn’t prohibit these closures from being declared for other purposes directly in the original view declaration as well!

But if we used this modifier as-is, our code would be a nightmare:

TaskRow(task: task)
        .modifier(AnalyticsEventTrackingModifier(service: self.analyticsService, groups: [AnalyticsEventGroup(trigger: .onAppear, events: [TaskRowViewed(task: task, list: list)])]))

So we need to clean it up with a view extension.

We start by working backwards from most complicated to least complicated. The most complicated call would involve tracking multiple events in response to multiple triggers. For that, we need a convenience function that takes an array of event groups and the service used to track:

extension View {

        /// Track all analytics events for the given groups using the provided service
    func track(with service: AnalyticsService, _ groups: [AnalyticsEventGroup]) -> some View {
        let modifier = AnalyticsEventTrackingModifier(service: service, groups: groups)
        return self.modifier(modifier)
    }
}

Then in our views, we’d use this convenience function like so:

List {
        ...
}
.track(with: analyticsService, [
        AnalyticsEventGroup(.onAppear, events: [
                TaskListViewed(list)
                SomeOtherEvent(param: something)
                YetAnotherEvent(param: somethingElse))
        ])
        AnalyticsEventGroup(.onDisappear, events: [
                TaskListClosed(list)
        ])
])

But this is overkill for the likely common case of tracking events in response to a single service:

TaskRow(task: task)
        .track(with: analyticsService, [
                AnalyticsEventGroup(.onAppear, events: [
                        TaskRowViewed(task: task, list: list)
                ])
        ])

So we simplify with another convenience function that accepts a trigger and array of events:

extension View {
        ...

        /// Track an array of events in response to the trigger with the provided service.
    func track(_ trigger: AnalyticsEventTrigger, with service: AnalyticsService, events: [AnalyticsEvent]) -> some View {
        let group = AnalyticsEventGroup(trigger, events: events)
        return self.track(with: service, [group])
    }
}

Then we update our view like so:

TaskRow(task: task)
        .track(.onAppear, with: analyticsService, events: [
            TaskRowViewed(task: task, list: list)
        ])

This is a marked improvement over our prior approach for a bunch of reasons. We avoid cluttering our lifecycle modifiers, we reference our analyticsService once per group of events rather than once per event, and we visually groups of events in a single track call.

But we can still do better, for one, by getting rid of all these clunky [] brackets and un-Swifty use of arrays.

Get cleaner syntax with result builders

Ever wonder how SwiftUI’s declarative syntax works? How a List can be declared as a bunch of Text statements or a .toolbar can take a bunch of items and “build” an actual toolbar out of them?

List {
        Text("First item in the list")
        Text("Second item in the list")
        Text("Third item in the list")
        Text("Fourth item in the list")
}.toolbar {
        ToolbarItem(placement: .navigation) {
            EditButton()
    }
    ToolbarItemGroup(placement: .bottomBar) {
            AddButton(...)
                FilterButton(...)
                SortButton(...)
        }
}

Under the hood, SwiftUI uses something called a ViewBuilder which takes a bunch of code statements and builds views out of them.

But view builders are just one kind of a broader type called result builders, which take code statements of any kind into whatever you might define (within certain limitations).

For example, we could create a result builder that takes a closure of statements, each of which represents an AnalyticsEvent, and use it to return an array of analytics events:

/// A builder resulting in an array of analytics events
@resultBuilder struct AnalyticsEventBuilder {

    /// Return an array of analytics events given a closure containing statements of analytics events.
    static func buildBlock(_ events: AnalyticsEvent...) -> [AnalyticsEvent] {
        events
    }
}

And we could do the same for AnalyticsEventGroup statements:

/// A builder resulting in an array of analytics event groups
@resultBuilder struct AnalyticsEventGroupBuilder {

    /// Return an array of analytics event groups given a closure containing statements of analytics event groups
    static func buildBlock(_ eventGroups: AnalyticsEventGroup...) -> [AnalyticsEventGroup] {
        eventGroups
    }
}

Then we can add an initializer to our AnalyticsEventGroup that takes an AnalyticsEventBuilder instead of an array of events:

extension AnalyticsEventGroup {

    /// Initialize with a trigger and event builder
    init(_ trigger: AnalyticsEventTrigger, @AnalyticsEventBuilder events: () -> [AnalyticsEvent]) {
        self.init(trigger, events: events())
    }
}

And from there, we could adjust our convenience functions for our view modifiers to accept instances of AnalyticsEventBuilder and AnalyticsEventGroupBuilder in lieu of arrays as well:

extension View {

        // Track all analytics events for the given groups
        func track(with service: AnalyticsService, @AnalyticsEventGroupBuilder _ groups: () -> [AnalyticsEventGroup]) -> some View {
            let groups = groups()
            let modifier = AnalyticsEventTrackingModifier(service: service, groups: groups)
            return self.modifier(modifier)
        }

        /// Track a group of events in response to the trigger with the provided service.
        func track(_ trigger: AnalyticsEventTrigger, with service: AnalyticsService, @AnalyticsEventBuilder _ events: () -> [AnalyticsEvent]) -> some View {
            let eventsArray = events()
            let group = AnalyticsEventGroup(trigger, events: eventsArray)
            return track(with: service, [group])
        }
}

Then, as a result (pun intended), tracking events becomes super slick and Swifty like this:

/// Multiple triggers, multiple events
List {
        ...
}
.track(with: analyticsService) {
        AnalyticsEventGroup(.onAppear) {
                TaskListViewed(list)
                SomeOtherEvent(param: something)
                YetAnotherEvent(param: somethingElse))
        }
        AnalyticsEventGroup(.onDisappear) {
                TaskListClosed(list)
        }
}

/// Single trigger, multiple events
TaskRow(task: task)
        .track(.onAppear, with: analyticsService) {
                TaskRowViewed(task: task, list: list)
                SomeOtherEvent(param: something)
                YetAnotherEvent(param: somethingElse)
        }

/// Single trigger, single event
TaskRow(task: task)
        .track(.onAppear, with: analyticsService) {
                TaskRowViewed(task: task, list: list)
        }

Isn’t that exquisite? Your event tracking code couldn’t blend in more naturally with the rest of your SwiftUI view code. Not to mention, the length of any given line is only about as long as any single event initializer plus indentation!

Leverage additional convenience functions for consistency

The only thing left is to tie everything back together. Using the above techniques, our original view code goes from this:

struct TaskListView: View {

    @Binding var list: TaskList

    var body: some View {
        NavigationView {
            List(list.tasks) { task in
                TaskRow(task: task)
                    .onAppear {
                        Mixpanel.mainInstance().track(event: "Task List Item Viewed", properties: [
                            "Task Type": task.type,
                            "List Title": list.title,
                            "List Type": list.type,
                                                        ...
                        ])
                    }
            }
                        .onAppear {
                Mixpanel.mainInstance().track(event: "Task List Viewed", properties: [
                    "List Title": list.title,
                    "List Type": list.type,
                                        ...
                ])
                                Mixpanel.mainInstance().track(event: "Some Other Event", properties: [
                                        ...
                ])
                                Mixpanel.mainInstance().track(event: "Yet Another Event", properties: [
                                        ...
                ])
            }
                        .onDisappear {
                                Mixpanel.mainInstance().track(event: "Task List Closed", properties: [
                                        ...
                ])
                        }
                        .toolbar {
                    Button("Add") {
                        Mixpanel.mainInstance().track(event: "Button Tapped", properties: [
                            "Button Name": "Add",
                            "Button Context": "Task List",
                                                ...
                        ])
                    }
                }

        }
    }
}

…to this:

struct TaskListView: View {

    @Binding var list: TaskList

    var body: some View {
        NavigationView {
            List(list.tasks) { task in
                TaskRow(task: task)
                                        .track(.onAppear, with: analyticsService) {
                                                TaskRowViewed(task: task, list: list)
                                        }
            }
                        .toolbar {
                    Button("Add") {
                        analyticsService.track(ButtonTapped(name: .add, context: .taskList))
                    }
                }
                        .track(with: analyticsService) {
                                AnalyticsEventGroup(.onAppear) {
                                        TaskListViewed(list)
                                        SomeOtherEvent(param: something)
                                        YetAnotherEvent(param: somethingElse))
                                }
                                AnalyticsEventGroup(.onDisappear) {
                                        TaskListClosed(list)
                                }
                        }

        }
    }
}

As you can see, it’s condensed and vastly more clear.

But it would be nice if analytics calls inside things like buttons had the same structure as the view modifiers, wouldn’t it?

All we need to accomplish this is a couple of additional convenience functions in our view extension that allow us to track events independent of triggers:

extension View {

    func track(with service: AnalyticsService, _ event: AnalyticsEvent) {
        service.track(event)
    }

    func track(with service: AnalyticsService, @AnalyticsEventBuilder _ events: () -> [AnalyticsEvent]) {
        let events = events()
        events.forEach { event in
            service.track(event)
        }
    }
}

Now we can can track a single event with the same style or multiple events in a closure from anywhere else in the view:

Button("Add") {
        track(with: analyticsService, ButtonTapped(name: .add, context: .taskList))
}

Button("Something Special") {
        track {
                ButtonTapped(name: .somethingSpecial, context: .taskList)
                VerySpecialEvent(...)
                MostSpecialEvent(...)
        }
}

Next steps

SwiftUI is an incredible framework that allows for UI development at rates that are orders of magnitude above many UIKit approaches.

But at its young age, it’s still not without growing pains that could impact the accuracy of your tracking data. We’ve heard reports of a variety of types of unexpected behavior that can sometimes occur in your lifecycle callbacks, so its important to test each view thoroughly to see where workarounds may be required, particularly as updates to SwiftUI are released.

That said, if you’re following the approaches above and simplifying your implementation, identifying and managing such hiccups will be that much simpler—not to mention allow you to fully enjoy SwiftUI as it was meant to be used.

About Joseph Pacheco

Joseph is the founder of App Boss, a knowledge source for idea people (with little or no tech background) to turn their apps into viable businesses. He’s been developing apps for almost as long as the App Store has existed—wearing every hat from full-time engineer to product manager, UX designer, founder, content creator, and technical cofounder. He’s also given technical interviews to 1,400 software engineers who have gone on to accept roles at Apple, Dropbox, Yelp, and other major Bay Area firms.

Gain insights into how best to convert, engage, and retain your users with Mixpanel’s powerful product analytics. Try it free.

How I went from struggling with math to becoming a data and analytics advocate

Mixpanel — Mon, 02 Aug 2021 22:26:02 +0000

This article was written by Mixpanel Community Manager Jaz Broughton and originally appeared on Mixpanel's product analytics blog, The Signal.

I’ve struggled with math since high school.

It wasn’t that I was incapable of doing simple algebra here and there. My hangup was the topic in general. I always had a hard time applying any real focus on the abstract shapes and concepts with no tangible connection to what I actually cared about.

I’m sure this was my dad’s philosophy rubbing off on me. He’s been a carpenter my whole life (and a DJ, but that’s a story for another time). As a child, I would hear him saying things like, “You’re not going to have me in a class just learning numbers for the sake of it.”

Well, today I lead the Mixpanel Community, a place full of stat-powered technical people discussing and learning about data tools. I’ve loved this job and the last several years of my career working in numbers—something that 16-year-old me would be surprised to hear.

How did I go from someone who ran from anything math-related to a professional advocate for data-led business practices?

Below is my story about finding a connection to math and the advice I give to people every day who want to overcome their own quant struggles to unlock the power of data and analytics in their work.

Putting faces to the numbers

There was no single lightbulb moment for when I “got” math—just a series of career moments that showed me, over time, that I’m not bad at it. As time went on, the more and more I saw how numbers connected to business and to processes, things became clearer.

I started out as a property manager and administrator in the hospitality industry. As part of the role, I was involved in a six-week project to adjust room rates based on a large dataset (all in spreadsheets). I didn’t set up the math behind it, but I saw the result: the projected revenue from certain rates at certain times. Very cool and very useful! (I’d eventually learn this is the same kind of cause and effect product teams analyze when developing a product.)

Over time, I learned the tools myself—how to pull the right data, how to plug it in, and how to read the results. It was only when I happened into a revenue management role that the next big revelation came: Working with math and data in the real world meant it wasn’t just empty numbers; it was people and price points.

I could get my head around the numbers in the right context. That not only made math more manageable, but it also made it more interesting.

Even with that realization, my first foray into tech wasn’t in a data or revenue role; it was in Customer Success (a role I’m still very much passionate about). Then, after a few more years, I would combine the two: the people-focus of Customer Success and the hard numbers of revenue and product analytics.

My new career in data and analytics

My Customer Success Manager role wasn’t numbers-focused on its face, but I quickly found out how helpful data and analytics could be in the job.

I could sit down, pull up MongoDB, pull in some stats, and run some chart drops. Suddenly I had a better picture of what works and what doesn’t with the customers we were working with. The technology itself is what made me feel more confident with numbers.

Most of the time, success teams rely on phone calls with clients and generous users reaching out to report what’s working and what’s not. But data tools allowed me to see, in black and white, exactly what was happening—and then make some educated guesses around why it was happening. Even if it was just a simple /TRUE/FALSE boolean column in a .csv file, the data gave me what I needed.

Then things took another (favorable) turn.

My first experience with Mixpanel came when I was working with another company. We were doing a rollout with a customer that had 900 employees and I wanted to see how the team had been using the training materials. I went to a product manager and, instead of pulling up a spreadsheet, he pulled up Mixpanel. A couple of clicks later, I had all the information that previously would’ve meant spending a full day in spreadsheets.

I was hooked.

My badge of honor, after all, isn’t in me doing the calculations myself. It’s all about being able to pull together trends, identify themes, and present options all based on data. Now I knew there was a tool that would help me do all that.

How to build a data-focused mindset

Sticking with a data-first approach is something I carried with me into my Customer Success Manager role with Mixpanel, and it’s something I continue to carry in my role as Community Manager.

I want to know the numbers: How many people should I invite to this? How many people show up? How long did people stay? Where did they drop off?

If you’re looking for that in your own role, you don’t have to start from scratch. Ask someone (a product manager, a more experienced rep, or even someone from the data science team) to show you how. Then iterate and learn from there. My first step into data and analytics wasn’t onboarding with some fancy tool. I just asked someone to show me how to pull data into a .csv and run some simple analyses.

The same can be true for your foray into product analytics. What’s most important are the questions you’re asking, not necessarily the (more scary) numbers. In nearly every conversation I have with the Mixpanel community, I share my six steps for wrapping your head around analytics:

Role & Purpose: What is the point of your role?
Goal: What does success look like? What are you driving?
Question: What do you need to know? What are you curious about? What remains a mystery?
Report: Which report is best for this? Do you have an understanding of the different reports?
Query: Translate that question into the query. Think of reporting period, visualization, level of detail, or level of summary.
Answer: Get the insight and use it to inform how you approach your goals and fulfill your purpose!

The best product analytics tools make these steps easy, especially when you can copy from your colleagues who have gone before you.

Creating Community—with the power of data

Here’s the TL;DR version: In the last few years, I’ve managed to turn math and data into work that I genuinely enjoy.

It’s not that I’ve gotten better at math—it’s that I’ve gotten better at wielding what I know to help people. I can see what people are doing and I can see what people need, even before they raise their hand. With data, a simple post is more than that—it means someone is curious about the maturity of their product and team, whether they’re a solo product manager, an enthusiastic grad or a time-poor startup founder.

With this approach, I’m helping to make the Mixpanel Community a place for genuine insight, inspiration, and connection for data-curious people. Please come say hi!

For me, looking for the numbers in things has opened up so many new and exciting opportunities, and I hope that my story proves anyone has the capabilities to do the same—the math-averse included. Even dad has finally learned the usefulness of crunching numbers for a good cashflow outlook.