This is likely about Twitter getting creepy. Every online advertising company is worried about the growth of the mobile environment, because it's harder to do all of the tracking that they're used to on those platforms. There are no cookies that follow you across apps.
The cookie equivalent in the mobile world is the SDK. Rather than scattering your "like"/"tweet"/"follow" buttons all over the web to track users' movements, you embed your SDK into everyone's apps to do the same thing.
If you are currently a Crashlytics customer, think about how much information is being transmitted to Crashlytics from your app, and what Twitter is going to be able to do with that now.
Interesting thought. Any idea how many apps use Crashlytics? There's lots of value in knowing what potential competitor numbers are or even for other strategic reasons.
Pure speculation: This fits in well with other sdk platforms that complete the loop for advertising companies focused on mobile. Burstly (mobile ads) bought TestFlight (beta app distribution sdk). Flurry (mobile ads) gives away a free analytics sdk (Flurry Analytics). Now Twitter (ad company) has Crashlytics (crash reporting sdk). In each case, the free offering is a trojan horse to get insight into tons of aggregate data in order to power the advertising/recommendation engines of the parent company.
The only way I can see that this makes sense is if Twitter is going to become a web/mobile-wide ad company and start offering ad units across the web and/or other apps (like AdSense but with tweets as the ad unit).
There could be dozens of different/better reasons that this makes sense, but I can't see them at the moment.
Per my post above, I don't see how any company using Crashlytics continues to use them going forward. If you are a publisher, the last thing you'd want is Twitter having your data.
This looks like the Google Urchin deal (2005) which became Google Analytics. Google got its hooks into every web page/site with the Urchin deal. I guess Twitter is looking to do the same on mobile via Crashlytics. Good move.
Crashlytics has literally changed the game with regards to crash reporting. Their UI and customer service has been wonderful (unlike most other mobile service providers...) and I really hope they continue to offer their services to devs.
All the information provided at the top is done with great attention to beautifully rendered icons, and it's all totally useless for diagnosing a crash report.
This is supposed to be a development tool, not an advertisement.
Agreed, I've had limited experience with the product and was disappointed. I think the above comments are correct, Twitter wanted them for the data not the talent.
I don't have much experience with other Crash reporting systems for iOS besides Crashlytics, but I will say that overall I have been happy with them. The image you linked to leaves out the actual stack trace, but trust me it's there.
The reason I ended up going with them is that they are 1) The library is tiny and isn't bloated with things I don't need 2) It's integration with Jenkins is great. It automatically uploads my dsym with the correct build number and all crashes from that build get tagged with that build number. 4) Support is fast 5) Love supporting a local Boston company
I will say that some of their design is a little over the top, they certainly love skeuomorphism. One thing that kind of annoys me about their site is that the content is a fixed width. This is frustrating because they add "..." to shorten some labels to fit instead of using all the screen real-estate available.
I use it in production with an app that has >50K users. It shows you the exact lines, and break down where it happens. What you showed isn't even important.
I didn't see the part about twitter turning into a multiple-product company. They've kept Posterous alive but besides that, just about anything they've acquired has been rolled into their core product or dismantled. I'd welcome the change, but I really don't know whether to believe the part about Crashlytics continuing unabated.
It is an interesting acquisition - clearly, Twitter has a lot of use for the product internally, and they were probably one of, if not the biggest, client (in terms of raw data collected). There is something to be said for mitigating the risk that your third party suppliers disappear from under your feet.
I don't know what Crashlytics enterprise pricing structure is like, but if it's anything like other similar services they'll probably be on twelve month agreements with their clients, which would be complex to untie. I doubt the service will go anywhere for paying clients for a little while. If you're relying on a free third-party service in your apps you always have a recovery plan should something get bought, retired, or just plain go wrong.
They acquired Vine and just yesterday let them launch their product under Vine and stay in New York.
They acquired TweetDeck and changed it a little but the team and registered company still resides in England.
and as you said Posterous is the other example, although I wouldn't say that's really a Twitter product. They're just letting people leave that at their own will and eventually they'll just turn it off.
IMO, this acquisition could have been motivated by 1 or more of the following:
(1) Need them in house. Many larger companies have been contracting their app development to ISVs. Some ISVs have been quietly purchased by their largest customers, as mobile has become more "core". Crashlytics was a toolmaker that Twitter and some others used. Perhaps, Twitter thought these tools were "core", or too important to not have as part of their org.
I'd argue this isn't the primary motivator. Twitter could have benefited, and would arguably benefit more, if Crashlytics continued their mission external to Twitter as a straight crash diagnostic solution. If Twitter asked for something cool, Crashlytic would generally jump at the chance to deliver the functionality [w/ no acquistion]. From Crashlytic's perspective, assuming they ran a tight/"well attended" acquisition process, I would hypothesize a higher value from some one like Google (for dev tool for all their publishers + #3 upside + compliment to GA), and/or someone like NetDynamics/NewRelic/EMC. The APM people will eventually see the light, realizing they, too, can't afford NOT to have a mobile offering to their product offering (Facebook is to Instagram as …)
(2) Talent. Crashlytics has always had a competency in UI/UX + hardcore mobile engineering. Remember, they are toolmakers, the hard core of the hard core. These skills would be valuable to any company with a significant mobile presence. The UI/UX talent would benefit anyone.
Given the probable purchase price, anchored by their last round of funding (~$5-6M), pure talent motivations are unlikely due to investor return expectations driving high PP. If competitors had so drastically reduced Crashlytics ability to grow into a standalone business, then this might be a possibility. Even then, there are organizations who they could find to more highly value their particular skillets / current product *
(3) Re-purpose / Trojan horse. Since Crashlytics solution installs an agent inside someone's else app, you can begin delivering all types of services + collect all kinds of interesting info as part of a bundled offering:
- (3A) Event logging. Call this the Flurry/GoogleAnalytics play. Every time an instrumented app does something, speaks to the outside world, or most likely, a user takes a certain set of actions, the SDK can report to the mothership. This is particularly useful if you're looking to add tracking across Twitter properties (app, web, etc) and other apps.
- (3B) Social plumbing. Twitter might lost-lead this (give it a way for free) to make adding twitter functionality into any app very easy.
- (3C) Mobile infrastructure wedge. Secure a relationship with app developers, and do something more beneficial with those relationships than just selling them tooling. Burstly/Testflight is a good example, so is Flurry with advertising.
- (3D) Other. God only knows.
3A/3B/3C are a very likely. The "universal cookie" is the holly grail for advertising platforms, and no one has figured it out yet. I would argue Google is better situated to take this role (given control over ad network +leading mobile OS), but can't fault Twitter for trying. You could argue they are making the advertising platform move. If this is the move, they run the risk of alienating their relationships / running a cat/mouse game with the mobile OS platform owners
------------------------------------
So in summary, I'm going with mostly #3, with 1 & 2 as a secondary motivator. Whichever is the case, I'd keep a close eye on their ToS (the hips don't lie). #3 is scary every which way, for both consumers and app dev's. #3 is aggressive, and loaded with cat/mouse games from existing platforms. #3 is thinking big.
How does this play for the remaining players in the space? Either very good or very bad for Crittercism, uTest's Apphance, and Bugsense.
- Bad. There was always a high probability of mobile crash reporting becoming commoditized, and/or becoming a lost-leader for something else. I highly doubt Crashlyitcs is going to remain Twitter's gift to the mobile engineering organizations of the world (a 2nd Bootstrap of sorts)?
- Good. Competitors lost a very credible competitor today. The information and access Twitter would gain via an embedded monitoring agent inside lots of popular apps is very interesting. For example, Twitter would know coveted metrics like real-time MAU #'s for any app using Crashlytics SDK. There's a hypothesis that companies will pay for tooling, especially if they know and can control how the data will be used. This is only magnified, if the new owner has large incentives to misuse that information.
------------------------------------
[I was an early employee at a competitor. I left to join a new startup ~5 months ago]
I don't see how it works as a Trojan horse. I don't think it plays - all the apps using Crashlytics will switch to a different service rather than have their data flow to Twitter. No way Expedia wants their data flowing to Twitter (or anyone else).
Looks to me like a talent acquisition. While Crashlytics was likely popular, I think they likely had limited revenue opportunities given Hockey App and Crittercism.
Really - it's a race to the bottom on these crash services. Switching costs would seem to be pretty low - so my guess is that the VCs saw a quick out.
I agree. We were an early Crashlytics adopter that also used TestFlight for Ad Hoc testing. When TestFlight launched TestFlight Live and introduced its own crash logging service, we saw no need to keep both in the app and shut off Crashlytics. Anecdotal of course, but I think the theory here has merit: crash logging is a feature, not a business model, and the Crashlytics team made a good move here.
Is there a list of other Twitter acquisitions, and how they've turned out (i.e. product vs. talent, and whether products were kept independent vs. rolled into Twitter)? I haven't really seen much about them as an acquirer vs. Facebook or Google, but that might just be my focus.
To be honest I did not know that. However, I do wish (quite often) that Apple would acquire TestFlight and make the service more stable. Can't live without it. But I suppose now Burstly must be on Twitter's radar, too.
The cookie equivalent in the mobile world is the SDK. Rather than scattering your "like"/"tweet"/"follow" buttons all over the web to track users' movements, you embed your SDK into everyone's apps to do the same thing.
If you are currently a Crashlytics customer, think about how much information is being transmitted to Crashlytics from your app, and what Twitter is going to be able to do with that now.