5 ms·

Mobile Analytics Platform Amplitude (YC W12) Takes On Flurry and Mixpanel

46 points by sskates 13y ago

sskates 13y ago
Really proud of the entire team on getting us here! Happy to answer any questions you guys have.
sskates2 13y ago
Way to go guys! Keep up the great work and momentum.
seivan 13y ago
Went through their iOS SDK. What's up with people shoving so much shit into their public facing API (the interface). I don't need all those comments if you could name your selectors properly (which you did) You took a file that could be visible on my 13" and made it huge and bloated. Still going through the implementation but there are a few flags. (Will do issues or PRs) Yes I am bored and caffeinated at 11 pm. Sorry for being overly negative, you did actually have cool stuff that Mixpanel missed out on. Like giving actual readable device names.
- sskates 13y ago
  Thanks for taking a look at our SDK. We actually put in all the comments on the interface file to clear up confusion people had when using the API.
  - seivan 13y ago
    Yeah I figure, but notice how Apple keep their documentation outside of their interface file. Try that. It makes it easier to learn.
  - seivan 13y ago
    You probably want to do three things 1) Extract all network layer into its own stuff. We built an SDK recently, and I decided to make three layers out of it. SDK -> OAuth2 -> Networking 2) Separate that 1000 lines of code into several classes (check #1) 3) Update your device naming https://github.com/seivan/mixpanel-iphone/blob/feature/proper_naming/Mixpanel/MPDeviceNamer.m https://github.com/seivan/mixpanel-iphone/blob/feature/prope... You guys will run into a case where your users will pollute their tracking with unknown model names because your SDK was outdated on the naming. Even if they do update the SDK, the users will have ton of data with the old naming. I'd probably store the device naming map on the server side in case of new devices without having to update the SDK. Also, write tests, add a sample app, add your cocoapod spec file to your repo as well - etc.
    - sskates 13y ago
      Thanks for the suggestions! We're on cocoapods, have tests, and a sample app locally but haven't pushed all that to Github to keep things simple for everyone looking at the source. Model name tracking is an issue- we've fixed it in our backend so we can remap unknown names to display the correct thing on our website interface. We just haven't yanked the code from the SDK. Agree on rearchitecting it with separation of concerns. We have to be very careful with any changes we push. The code's already running successfully on 10MM phones without any issues and we have to make sure not to introduce any new ones- so that process takes a while. Thanks again!
      - je42 13y ago
        If you have a complete suite of unit tests, integration tests and system tests, you should not have fear on refactoring your code. Question: do you store events that could be not send in a persistent store to retry at a later stage ?
        sskates 13y ago
        It's true that tests are very helpful for this. However there are a lot of bugs in the wild that are difficult to reproduce, especially ones that will only crop up under rare conditions of state. It's as Linus said- "There really are only two acceptable models of development: think and analyze or years and years of testing on thousands of machines". Years and years of testing on thousands of machines happens to be the best predictor of code that runs correctly.
      - je42 13y ago
        [Amplitude generateRandomId]; --> is that persistent per device ?
        sskates 13y ago
        It's persistent across app opens, not across installs though. We were using AdvertiserID for tracking but Apple started clamping down on that so we've switched over to to vendor ID, which they explicitly recommend for things like this.
- teacup50 13y ago
  > You took a file that could be visible on my 13" and made it huge and bloated. You're angry about this? https://github.com/amplitude/Amplitude-iOS/blob/master/Amplitude.h https://github.com/amplitude/Amplitude-iOS/blob/master/Ampli... Selector naming isn't a replacement for documentation, unless you happen to know how to express invariants like these entirely through naming and the type system: "Property keys must be <code>NSString</code> objects and values must be serializable." Also, I think the problem you might be having is that you're trying to hold other people's software to the constraints of your particular way of using a 13" consumer laptop.
  - bobbles 13y ago
    GitHub Feature request? (Remove commented lines checkbox)
CameronBanga 13y ago
Was excited after visiting that landing page, but woof on the pricing. We do custom app development for a variety of large companies, so do hear "analytics, analytics, analytics" all the time. But I would just hear "go with Google Analytics" at those prices.
- sskates 13y ago
  We're actually cheaper than Google Analytics at really large scale. One of our most recent customers was recently forced upgrade to Google Analytics Premium because they were tracking too much data and decided to come to us instead because we were cheaper.
vecter 13y ago
The mobile analytics ecosystem is in need of an overhaul. None of the existing players offer a great solution, least of all Flurry. Really excited to see how much further Amplitude can take things.
- ares2012 13y ago
  I'm curious, what is it that Flurry does not do well? Most of our customers are very happy.
  - jazzychad 13y ago
    I'm not OP, but I do have a question I've been trying to get answered from Flurry for over a year. How do I see breakdowns of properties I set on events? I can't find any way to do this in the Flurry reporting dashboard. Mixpanel brings this information front and center.
    - ares2012 13y ago
      Sorry for the delay, I must have missed this one. If you go to Events and select the event you are interested in, there will be a Pie Chart icon that allows you to click through to the properties data.
je42 13y ago
Site is down :(
- sskates 13y ago
  Affected by the Namecheap DDOS today unfortunately. Just switched over to Amazon Route 53 but it's taking a while to propagate to everyone.
  - je42 13y ago
    Thanks. works again.
Oatary 13y ago
Amplitude (YC W12) vs Mixpanel (YC S09)
melling 13y ago
Are there any good iOS analytics that break out the non-US markets? How well is Apple doing in countries like Brazil, South Korea, or Turkey, for example? Android has 80% of the world market so it's tough to know where iOS has significant market share.
- sskates 13y ago
  If you're curious about it for your own iOS app, we have that data for you. We keep all app data private to the app developer though, so we can't share aggregate statistics.
  - josephlord 13y ago
    Can you explain your policy on using and sharing aggregate statistics? Your privacy policy allows you to collect them but from my quick glance I hadn't realised you didn't share them.
    - sskates 13y ago
      We don't share data to any third parties. We do look at aggregate traffic internally to ensure we can meet demand. We also will go into people's accounts if they ask us to for support. I'll make that more explicit in our policy.
      - josephlord 13y ago
        Great, I will probably give you a try when I get a chance.
  - melling 13y ago
    I'd like to know which markets are worth translating to. I've done Chinese and Russian and they've done well.
brandonb 13y ago
Congrats Spenser, Curtis, and the rest of the team!
- sskates 13y ago
  Thanks Brandon!
tribe2012 13y ago
I've used Mixpanel for some time. It does most of what it's supposed to but I'm not a huge fan. I can't wait to check them out.
- sskates 13y ago
  Thanks for taking a look! Email me at spenser@amplitude.com
seddona 13y ago
Congrats guys, looks great!
- sskates 13y ago
  Thanks Andrew!
blader 13y ago
Super happy customer here. Not many analytics companies give you raw SQL access to your data - it's pretty clutch if ever you need to get insights that you can't get from a service's web dashboard (which is basically all the time if you're doing any serious analysis).
- sskates 13y ago
  We're really glad to have you as a customer, Siqi!
dozy 13y ago
Yeah yeah, the Android code suffers from the same lack of good OO design/code organization as the iOS code, but frankly it's such a simple sdk, it won't matter until it's feature rich and complicated. Anyways, some immediate concerns as I see it: 1. Sending requests every 10 seconds (and/or at every onPause) is no-good for battery life. Please, let the radio power down once in a while! 2. Using DefaultHttpClient with no connection pooling 3. It's doing a ton of work, allocating objects, logging events, in every onResume/onPause...I don't like this design. That includes when I get a pop-up message from another app, even if I dismiss it immediately. 4. Would be nice to register for activity lifecycle callbacks for api level >= 14, so people can't screw up the implementation.

46 points by sskates 13y ago

sskates 13y ago

Really proud of the entire team on getting us here! Happy to answer any questions you guys have.

sskates2 13y ago

Way to go guys! Keep up the great work and momentum.

seivan 13y ago

Went through their iOS SDK. What's up with people shoving so much shit into their public facing API (the interface). I don't need all those comments if you could name your selectors properly (which you did) You took a file that could be visible on my 13" and made it huge and bloated. Still going through the implementation but there are a few flags. (Will do issues or PRs) Yes I am bored and caffeinated at 11 pm. Sorry for being overly negative, you did actually have cool stuff that Mixpanel missed out on. Like giving actual readable device names.

sskates 13y ago
Thanks for taking a look at our SDK. We actually put in all the comments on the interface file to clear up confusion people had when using the API.
- seivan 13y ago
  Yeah I figure, but notice how Apple keep their documentation outside of their interface file. Try that. It makes it easier to learn.
- seivan 13y ago
  You probably want to do three things 1) Extract all network layer into its own stuff. We built an SDK recently, and I decided to make three layers out of it. SDK -> OAuth2 -> Networking 2) Separate that 1000 lines of code into several classes (check #1) 3) Update your device naming https://github.com/seivan/mixpanel-iphone/blob/feature/proper_naming/Mixpanel/MPDeviceNamer.m https://github.com/seivan/mixpanel-iphone/blob/feature/prope... You guys will run into a case where your users will pollute their tracking with unknown model names because your SDK was outdated on the naming. Even if they do update the SDK, the users will have ton of data with the old naming. I'd probably store the device naming map on the server side in case of new devices without having to update the SDK. Also, write tests, add a sample app, add your cocoapod spec file to your repo as well - etc.
  - sskates 13y ago
    Thanks for the suggestions! We're on cocoapods, have tests, and a sample app locally but haven't pushed all that to Github to keep things simple for everyone looking at the source. Model name tracking is an issue- we've fixed it in our backend so we can remap unknown names to display the correct thing on our website interface. We just haven't yanked the code from the SDK. Agree on rearchitecting it with separation of concerns. We have to be very careful with any changes we push. The code's already running successfully on 10MM phones without any issues and we have to make sure not to introduce any new ones- so that process takes a while. Thanks again!
    - je42 13y ago
      If you have a complete suite of unit tests, integration tests and system tests, you should not have fear on refactoring your code. Question: do you store events that could be not send in a persistent store to retry at a later stage ?
      - sskates 13y ago
        It's true that tests are very helpful for this. However there are a lot of bugs in the wild that are difficult to reproduce, especially ones that will only crop up under rare conditions of state. It's as Linus said- "There really are only two acceptable models of development: think and analyze or years and years of testing on thousands of machines". Years and years of testing on thousands of machines happens to be the best predictor of code that runs correctly.
    - je42 13y ago
      [Amplitude generateRandomId]; --> is that persistent per device ?
      - sskates 13y ago
        It's persistent across app opens, not across installs though. We were using AdvertiserID for tracking but Apple started clamping down on that so we've switched over to to vendor ID, which they explicitly recommend for things like this.
teacup50 13y ago
> You took a file that could be visible on my 13" and made it huge and bloated. You're angry about this? https://github.com/amplitude/Amplitude-iOS/blob/master/Amplitude.h https://github.com/amplitude/Amplitude-iOS/blob/master/Ampli... Selector naming isn't a replacement for documentation, unless you happen to know how to express invariants like these entirely through naming and the type system: "Property keys must be <code>NSString</code> objects and values must be serializable." Also, I think the problem you might be having is that you're trying to hold other people's software to the constraints of your particular way of using a 13" consumer laptop.
- bobbles 13y ago
  GitHub Feature request? (Remove commented lines checkbox)

CameronBanga 13y ago

Was excited after visiting that landing page, but woof on the pricing. We do custom app development for a variety of large companies, so do hear "analytics, analytics, analytics" all the time. But I would just hear "go with Google Analytics" at those prices.

sskates 13y ago
We're actually cheaper than Google Analytics at really large scale. One of our most recent customers was recently forced upgrade to Google Analytics Premium because they were tracking too much data and decided to come to us instead because we were cheaper.

vecter 13y ago

The mobile analytics ecosystem is in need of an overhaul. None of the existing players offer a great solution, least of all Flurry. Really excited to see how much further Amplitude can take things.

ares2012 13y ago
I'm curious, what is it that Flurry does not do well? Most of our customers are very happy.
- jazzychad 13y ago
  I'm not OP, but I do have a question I've been trying to get answered from Flurry for over a year. How do I see breakdowns of properties I set on events? I can't find any way to do this in the Flurry reporting dashboard. Mixpanel brings this information front and center.
  - ares2012 13y ago
    Sorry for the delay, I must have missed this one. If you go to Events and select the event you are interested in, there will be a Pie Chart icon that allows you to click through to the properties data.

je42 13y ago

Site is down :(

sskates 13y ago
Affected by the Namecheap DDOS today unfortunately. Just switched over to Amazon Route 53 but it's taking a while to propagate to everyone.
- je42 13y ago
  Thanks. works again.

Oatary 13y ago

Amplitude (YC W12) vs Mixpanel (YC S09)

melling 13y ago

Are there any good iOS analytics that break out the non-US markets? How well is Apple doing in countries like Brazil, South Korea, or Turkey, for example? Android has 80% of the world market so it's tough to know where iOS has significant market share.

sskates 13y ago
If you're curious about it for your own iOS app, we have that data for you. We keep all app data private to the app developer though, so we can't share aggregate statistics.
- josephlord 13y ago
  Can you explain your policy on using and sharing aggregate statistics? Your privacy policy allows you to collect them but from my quick glance I hadn't realised you didn't share them.
  - sskates 13y ago
    We don't share data to any third parties. We do look at aggregate traffic internally to ensure we can meet demand. We also will go into people's accounts if they ask us to for support. I'll make that more explicit in our policy.
    - josephlord 13y ago
      Great, I will probably give you a try when I get a chance.
- melling 13y ago
  I'd like to know which markets are worth translating to. I've done Chinese and Russian and they've done well.

brandonb 13y ago

Congrats Spenser, Curtis, and the rest of the team!

sskates 13y ago
Thanks Brandon!

tribe2012 13y ago

I've used Mixpanel for some time. It does most of what it's supposed to but I'm not a huge fan. I can't wait to check them out.

sskates 13y ago
Thanks for taking a look! Email me at spenser@amplitude.com

seddona 13y ago

Congrats guys, looks great!

sskates 13y ago
Thanks Andrew!

blader 13y ago

Super happy customer here. Not many analytics companies give you raw SQL access to your data - it's pretty clutch if ever you need to get insights that you can't get from a service's web dashboard (which is basically all the time if you're doing any serious analysis).

sskates 13y ago
We're really glad to have you as a customer, Siqi!

dozy 13y ago

Yeah yeah, the Android code suffers from the same lack of good OO design/code organization as the iOS code, but frankly it's such a simple sdk, it won't matter until it's feature rich and complicated. Anyways, some immediate concerns as I see it: 1. Sending requests every 10 seconds (and/or at every onPause) is no-good for battery life. Please, let the radio power down once in a while! 2. Using DefaultHttpClient with no connection pooling 3. It's doing a ton of work, allocating objects, logging events, in every onResume/onPause...I don't like this design. That includes when I get a pop-up message from another app, even if I dismiss it immediately. 4. Would be nice to register for activity lifecycle callbacks for api level >= 14, so people can't screw up the implementation.