Skip to content
This repository has been archived by the owner on Aug 22, 2018. It is now read-only.

Analytics on Mobile #104

Open
mennenia opened this issue Sep 7, 2016 · 1 comment
Open

Analytics on Mobile #104

mennenia opened this issue Sep 7, 2016 · 1 comment

Comments

@mennenia
Copy link
Contributor

mennenia commented Sep 7, 2016

I had a great chat with @anipetrov today, which led to the idea that it may be time for us to revisit our current analytics strategy and setup.

Personally, I think analytics can provide us with very valuable data. Especially considering we don't user test much, and as our audience is fairly niche (we are targeting collectors currently, rather than your everyday person, although that may again be the goal one day). This means that analytics is extra important to us in order to figure out what our users look at, what actions they attempt and succeed at, and what we can offer them.

Furthermore, with React Native starting to creep in, what's the best way for us to trigger events from there? Do we bridge all the actions and taps, do we send analytics separately from within our RN views, or do something else entirely?

Analytics can easily creep into your codebase and spread everywhere. What ARAnalytics has done beautifully is keep it all contained in one file and separately. Is there a way we can start adding more information to that though?

As an example of what would be useful to start tracking:

  • Unique IDs for each screen + firing an event every time they appear
  • The referring screen - where did the user come from when they landed on this artwork?
  • On which screen an action happened / where an action was triggered from (for example, log in)

@orta mentioned breadcrumbs similar to what happens when crashes are reported. Apparently, ARAnalytics also knows what the last few fired events were. Can we chain them somehow?

Finally, how similar and different are we to Force? Do we want to achieve greater similarities there, so it's easy to compare web vs mobile?

Yes this would be quite some work. It's a project. It requires rethinking a few things. But like I said, I think it'd be very worth it.

Would love to hear everyone's thoughts on this, high or low level as to how you think we could approach this. @orta @ashfurrow @sarahscott @alloy

@anipetrov feel free to chime in on what type of info you'd love to receive / what you're looking for from your end.

@orta
Copy link
Contributor

orta commented Sep 7, 2016

Quickie:

From ARAnalytics side, we could also include a context object in the params:

@{
    ARAnalyticsClass: ARProfileViewController.class,
    ARAnalyticsDetails: @[
        @{
            ARAnalyticsEventName: ARAnalyticsProfileView,
            ARAnalyticsSelectorName: NSStringFromSelector(@selector(loadMartsyView)),
            ARAnalyticsProperties: ^NSDictionary*(ARAnalyticsContext *context, ARProfileViewController *controller, NSArray *_) {
                if (context.lastEvent[@"path"] isEqual: @"/artwork/*") { 
                    return @{ @"different" : @"thing" };
                }
                return @{
                    @"profile_id" : controller.profileID ?: @"",
                    @"user_id" : [[ARUserManager sharedManager] currentUser].userID ?: @""
                };
            }
        }
    ]
},

Could provide useful metadata there.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants