Twitter acquires Crashlytics
crashlytics.com
crashlytics.com
(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]
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.
Congrats to the team for the acquisition.
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.
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.
Drill down on a crash for example: https://d1f4seebrc9wq7.cloudfront.net/blog/wp-content/upload...
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.
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.
So they support DWARF and backtraces. Just like everyone else.
> What you showed isn't even important.
Yes, exactly.
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 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 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.
Not so good for the current clients of Crashytics though. Are the other tools/services that provide good crash analytics?