Stripe Sigma
stripe.com
stripe.com
> We've had beta access to it for a while and have known it was coming. Generally not worried about it at all nor do we view it as any sort of competition in any sense of the word.
> It doesn't give access to any new data...it's an SQL wrapper on top of their API (albeit a very pretty one).
> What we've found over the years is that you really need more data sources to make real decisions. So, yes, Stripe has a lot of data, but it only tells you part of the story. And that’s the thing here…Stripe’s not trying to “tell stories” with the data in Sigma. They’re just giving you a specific tool to access the data points.
> Baremetrics, however, is focused on telling the story. We want to help businesses know what to do with the data, not just slice and dice it in to spreadsheets.
> So, in summary, I think it’s neat but it won’t be anything for us to worry about from a competitive standpoint as we’re solving different problems.
That was all on-the-record, obviously, or I wouldn't share it.
Edit: Additionally, the pricing seems a bit much considering that Stripe is already making a good deal of money off of their users transactions and it isn't so much trouble to write your own queries via their api.
If we used subscriptions in Stripe, we'd use Baremetrics. But we manage subscriptions using third party software, so their metrics/products are unfortunately not a great fit.
What's preventing Stripe from having a story-like dashboard?
For the record, here are some screenshots I found on Google Images of Stripe and Baremetrics's dashboards: http://imgur.com/a/s4V8u
Basically we create a customer-specific database whose contents are all derived from our real OLTP database, and give them read-only access to it. In our case they also have to be on a VPN, but we've talked about adding a web-based SQL console like I see here.
It's funny that at first this approach sounds crazy, but really it is what companies have been doing since the 90s: creating flattened read-only reporting databases. If you want to do this, you should read Ralph Kimball's _Data Warehouse Toolkit_ for some inspiration and guidance.
Of course you don't want to give customers access to your OLTP database. Besides the security and performance problems there, if your core database becomes a public API, it is frozen and you can never add another feature again. But a separate reporting database still gives you plenty of flexibility to grow.
My second reaction is 'oh, thank god'. I'm so tired of having APIs where I have to go through the 'get the list of users', 'iterate over the list to create a map', 'get the list of messages', 'iterate over the list of messages and add the username to the data structure', 'oh wait I have to get the channel list separately too, seriously?', 'get the list of channels', 'iterate over the list to create a map', etc.
I love Slack's API, for example, but having to fetch a list of users, along with the entirety of their profile data and everything about them, then do the same for channels, then do the same for messages, then tie everything together, it's very cumbersome compared to
SELECT m.message, m.when, u.username, u.name, c.name FROM messages m LEFT JOIN users u ON (m.uid == u.uid) LEFT JOIN (m.cid == c.cid) where c.name == "#general" LIMIT 50;
(or whatever it should be, I haven't done SQL in ages)
And I also get a lot fewer records, especially when I'm trying to get the last 50 messages from #general on a Slack instance that has 400 users and 200 channels.
> Additional processing time–up to 48 hours–is required to make your account’s transactional data available in Sigma. This means that it does not reflect your account’s most recent data and should be considered a couple days behind. The Sigma interface displays the date and time of the last update to your data.
I can understand an async mode of updates being partially behind but two days seems excessively laggy without a business reason for it.
Given how Stripe seems to build products in a lean way, it'd not surprise me if they are just launching like this and measure customer reaction. If the main reason it doesn't get the traction they want is the 48 lag, they'll just rewrite their reporting pipeline to use streaming, and the product gets faster for free.
We are a fairly long-running Stripe customer, and we mirror all transaction data, with the exception of actual card info, into our internal dbms. I am presuming nearly all Stripe customers do this as well, considering how easy API integration is. So what is the utility of this service versus querying internal data - particularly when one can join on data sets that Stripe has no access to?
A lot of customers don't in fact do that. I've been working a bunch on dj-stripe (https://github.com/kavdev/dj-stripe) and trying to make it work exactly like that, but before that at the very least it's pretty safe to assume that most Django apps using Stripe only had a fraction of the data you can pull from Stripe.
It's also only a model you really need for subscriptions. For one-off charges, all you need is a copy of whatever data you care about in the charge and invoice models.
The act of reconciling the list of transactions you have stored in your database with what the source of truth has is an important process for finance teams.
They moved to Stripe for payments years ago, and it's helped them out a lot with simpler integration and more data. Sigma looks great for them.
They're not a big outfit, they don't have a dedicated engineering3 dept or developers on staff. Their main business is making chocolate after all.
With Sigma they can more easily query their transaction data and get all sorts of insight. My friend has degrees in Chemical Engineering and Nutrition, she's a smart woman and can do a lot more with excel that I can muster. Although she learned some coding in engineering school, using the APIs directly is a lot to ask. SQL is much more accessible, and was originally developed for business professionals just like her. So I expect something like this will help her go from periodic data imports and excel-based analysis to much more frequent, maybe daily, reports and analysis.
This is a great-looking product.
Note: I'm specifically excluding Redshift which requires active management
Err... we push seven figures a year through Stripe, and we don't do this.
Though the point about data sets is important: even if we have the metadata here, ultimately it's only a partial view into money we're receiving.
But if Stripe is your only payment process, this is definitely interesting.
I think you answered your own question!
Although at first glance, it looks quite expensive. Having to pay $10 monthly outright even with no charges feels kinda bad. I'm a huge fan of Amazon's free tiers to experiment with; Stripe's test mode is very nice for the same reason. And on top of this, the pricing being per-charge makes it far more expensive for businesses selling cheaper products ($5 subscriptions vs. $100 subscriptions).
Compare to Baremetrics' pricing plans which scales based on MRR: https://baremetrics.com/pricing -- At $50k MRR with $5 charge avg, Baremetrics costs $100/mo, Sigma costs 2.5x that. For $2.5 avg charge, Sigma costs double, Baremetrics remain the same.
They still sound like very reasonable prices though (and Stripe's fees are unfriendly to lower price points anyway).
What?! Where does a single cup of coffee cost five dollars?
For ten dollars, you can brew at least fifty cups of coffee.
The (TM) alone adds $0.50 to the price of a cup.
Stripe sells to businesses, they aren't gonna drive their bottom line off $10/mo.
* Is the expectation that everyone can write SQL?
* If the customer can write SQL and they're sufficiently large, won't they export the data into their own in-house data architectures to use the tools and processes they already have?
* Is data exporting that hard from stripe that they decided to offer a query tool instead?
I'm thinking they're going after the lower end of the customer base, the customers that may have medium to small transaction volumes. Plus those customers might not yet have any data warehousing to speak of.
If I was BareMetrics, I would be especially concerned because it will be a matter of time before Stripe has their own compelling offer that does almost everything it does and more. There have been other examples of building businesses around other companies APIs (granted theres always exceptions to the rule but I want to point out its a huge risk):
https://news.ycombinator.com/item?id=9512441
https://techcrunch.com/2012/10/14/why-you-shouldnt-build-a-b...
This would have to be worrying for companies like Baremetrics, ChartMogul etc.
Obviously it is not 100% the same - but the ability to quickly get MRR, ARR etc would solve many peoples main pain.
See: twitter 3rd party devs, Buffer, Facebook app devs, etc
Stripe isn't a payment processor; they are your financial back office as a platform.
Well, they're getting there; Metrics were the #1 missing piece from Stripe, so it's good to see this. Dealing with EU VAT is still a massive pain though.
And since they have the financial data, they could proactively recommend the most cost-effective service to switch to. Kind of like a Credit Karma model.
So, what does this software actually do? My company uses Stripe and it is not immediately clear.
Imagine if you were a small and/or non-technical shop who used Stripe for your payments. This offers a window to produce good looking reports about the business without needing to keep track of that information in parallel outside of Stripe.
They have all sort of pre-run queries for MRR, Payment Methods, etc. which offers _huge_ benefit to those people who can get some great insights for no added work.
except for this one major bug... http://imgur.com/a/UWrcC
In case any Stripe-people are lurking here, the scrolling on the example query modals (the ones you get from clicking on e.g. "How many active customers do we have?") is painfully slow -- as though it had only been tested for Mac touchpads, where scrolling quickly is easy.
I'm on Firefox/Ubuntu, using a shitty USB mouse with a scrollwheel.
P.S.: What demonym does Stripe use? "Striper" is a letter away from an embarrassing typo.
Stripe could have particular constraints that I'm not aware of, but it seems to an example of not-invented-here syndrome.
I was making some edits in iMovie last week when I started talking to this video production professional. He started asking me why I wasn't using something more powerful like Final Cut and judging me for it. Mind you I was using final cut at least a decade ago and knew all about its capabilities. But he failed to realize that for what I needed to do (cut clips and speed up / slow down segments and add an audio track), iMovie was simple to use and did everything I needed it to do. Lagom.
I'm willing to bet there are enough people who don't wish to complicate something simple and add another service to their workflow... and manage yet another user account... or build out custom dashboards... When all they want is to answer a simple yet important question like "which customers have not payed their invoices?"
I wrote something for Doctrine last year where I let my users query their own data using DQL. I had to write a TONNE of AST walkers to ensure that they weren't accessing entities they didn't have permissions to. Was a huge issue that I wish I didn't start :D (But one of those cool things when it was finished)
The SQL layer could probably just be an API client to the data they have already.
* connects to a database
* allows a database admin to write a query once (maybe for $50 a query) against your database
* allows the query to have variables and hints in the code
* visualizes the result set as various types of graphs
* for each variable, lets you set values and ranges and steps etc.
* runs the queries and generates reports
While this may not be terribly complex, it opens up the chance to run SQL on your business data without building or maintaining the pipeline itself for SMBs which may have limited resources.
If this is done well, that's a huge value. Data cleaning often takes more work than actually figuring out what queries you want to run against your data or running them.
Can you be more specific?
Certainly for us, ChartIO backed by our own database is far more useful, particularly as we want to join on account data, preferences, registration details, NPS data, etc, which is all in our database.
1) Is it possible to easy display this data in graphs over time?
2) Can we record non-Stripe billing in it? (some customers will pay by check)
Because the payment process alone just doesn't include enough data to create relevant analysis for us.
Compare to Netsuite and other similar platforms.
Always assume good faith... It makes everyone happier, including you.
I've personally had good results with it, but admittedly at lowish volume.
We’d love to hear what would make us work better for you. My email is brahn at stripe.com.
And you write that > 80% of the worlds issued cards are in the stripe db because they are once used via stripe? Are you sure about this number?
Can't say im much impressed by this sql interface 'feature'; It's more opening low level access then a feature, but that is just my humble opinion. And it is of course nice for techies having to work with, instead of specific 3rd party APIs.
Will there also be plain (not plaintext but simple) replication interfaces/APIs in the future that clients can run sql slave nodes (mysql/postgresql) with near realtime replication for local querying (privacy) and backup purposes? (and being able to continue to use the data even if stripe would be unaccessible/down)?