A couple of people have mentioned that Baremetrics should feel threatened, and that's where my mind went immediately too. I asked Josh Pigford for his reaction, and this is what he said:
> 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.
I'd have to agree with Josh. Sigma looks pretty cool because it would save me from having to write some custom query scripts that I have to do now. However it doesn't appear to be competition for the Baremetrics dashboard as far as I can tell. I'm a happy user of theirs and don't feel lured away by Sigma at all.
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.
Stripes ultimate mission is to increase the total GDP of the internet. The more transactions that are happening on the internet, the better it is for them. So, from a company standpoint whatever they can possibly do to ensure that companies have the best tools available from stripe is what they are going to do. How hard would it be to expand into Baremetrics product from what they already have? They say that they are not competing, but I think they are. They are both in the business of giving their customers the best possible metric tools, period.
I don't see them as competing products or services at all. In fact, it might only increase visibility.
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.
For established customers maybe not as there's a cost to switching but I'd be very surprised if this didn't have a hit on their signups going forward (once it's GA).
I've only glanced at this, but I love the idea of making your API be SQL. I did this recently for a company whose customers have a lot of "power users" who are not professional programmers but use tools like R, Excel, Tableau, or even Python. The customers are very happy with it! We saved a ton of time not building a JSON API, which our customers wouldn't be able to use anyway.
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 first reaction to seeing an SQL-based API is 'ugh'. SQL is complex and a little cumbersome, and easy to get wrong.
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.
A question I'm asking myself is the security one. Obviously the accessed databases only contain the customer's own information with read-only access. But how do you prevent resource exhaustion / DoS attacks trough overly complicated queries? This is the obvious vector that comes to my mind but I wouldn't be surprised if there were a few other ones similar to it.
Is the data freshness a joke? 2 DAYS to get data into the data warehouse? Stitch, Fivetran, Segment, and more can do way better than that without any internal hooks.... :/
> 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've seen plenty of reporting pipelines that are that slow over the years. If this was built on the cheap, so it just uses existing pipelines, and instead of working through streaming, it regenerates the world every night, a 48 max failure with some is not out of the question once you add some CYA magic. That would make this pretty cheap to make: Some website work, boxes for queries, and some security work to make sure data from other customers doesn't leak.
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.
It's payments. Miss a single row and customers will balk and scream at the missing $.45 that they think they are owed. Better to buffer with a longer SLA until you feel very confident that your pipeline is bulletproof before you try to approach 24 hours or less.
I'm sorry, but I don't grok the utility of this. Can someone "explain this like I am five"?
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 friend of mine is director of business for https://www.franschocolates.com/ , which is a great local Seattle family business that has grown up to be big thanks to a great product (Seriously good chocolate!).
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.
> I am presuming nearly all Stripe customers do this as well
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.
Your internal data might not be consistent with what is stored in Stripe. Since Stripe is the one processing the payments, it is ultimately the source of truth for all data regarding whether or not transactions went through, failure reasons, disputes... etc.
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.
Well if you had this, you could probably get along with this just this more often. Kinda like you can "just" use the dashboard for most businesses rather than doing a bunch of API stuff.
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.
Really cool! Signed up for the beta, excited to try it.
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).
Yeah I think this just means you aren't their target customer. I'm sure there are people out there who will see this and happily pay hundreds or thousands a month because this solves a burning problem for them.
Stripe sells to businesses, they aren't gonna drive their bottom line off $10/mo.
I was surprised as this as well. I wouldn't think running these queries on small datasets would take much computing resources and would provide a nice competitive advantage over other alternatives.
Being able to query your data in SQL is great. But to be really useful, you need to be able to join many different data sources. For example, if you want to estimate [cost of sales] / [lifetime value], you need to join your Stripe data with your Salesforce data. Thats why companies like mine (Fivetran) exist: to mirror all your data sources in a single SQL warehouse. If you use a ETL-as-a-service provider and a fully-managed warehouse like BigQuery, it's really not that hard to set up your own data warehouse that has all your data in it.
Interesting offering. I wonder who they're targeting with this and the problem they're trying to solve.
* 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):
SQL is quickly turning into the new Excel. Most excel power users at our company have picked up SQL easily. Our product, merchandising, marketing, finance, and operations have all managed to teach people SQL for everyday use. This tool is for them.
> We’ve already written the queries for the most useful reports for different types of businesses: From computing MRR to ARPU to analyzing the payment methods your customers prefer...
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.
I get excited whenever Stripe releases a new product because their demo pages are bar-none the best ever made. The attention to design is very, very nice.
As usual, another beautiful Stripe product page. Fantastic job! The product looks pretty awesome too.
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.
I'm not that familiar with Stripe, but my first impression is: why spend time on creating an inferior Metabase / Periscope / Power BI / Looker / mariusandra/insights clone? Just allow data export and if you really want to give a ready-to-use product to your customers, Metabase seems awesome for this kind of thing?
Stripe could have particular constraints that I'm not aware of, but it seems to an example of not-invented-here syndrome.
maybe in order to help with sales and retention? can't see how it can hurt.
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?"
Not a dumb question at all! We do not currently have an API for Sigma. Although, its a great idea and good feedback for the Sigma team. Hope you find good use of its current incarnation. Thanks!
This is the reporting interface I wish our product had. I tried out Sigma during the beta and was very impressed with it, especially the front-end. SQL is a bold choice but I think the right interface given the structure of Stripe data.
Is this going to finally allow us to get the same stats that are shown in the Stripe dashboard (like "gross volume" for the month)? Stripe has had no way to get an aggregate of transactions in a timespan - if you wanted to get the "gross volume" or any other sum or count, you'd have to iterate through every payment. Not very convenient when you have tens of thousands of transactions and want to show an up-to-date revenue number on your company dashboard.
Technically, how would something like this architecturally be structured? Curious how they would sandbox the user data and still provide a SQL like interface.
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)
* 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
I think this could be a good business. If you want to do it together, contact me: https://qbix.com/about
I have been pondering something like this for ages, as most solutions seem to be insanely expensive. Found this though recently fwiw http://activereports.grapecity.com/server/
Pardon my ignorance! Coming from background of building data pipelines. It seems to me like SQL on backend data. The UI is uber cool. What makes it different from any rdbms system with UI? am I missing something ?
Somewhat unrelated but anyone know what Stripe used to create that video run through - it looks really slick and would love to discover some tools to make recording and annotating these kind of videos easy.
[+] [-] exolymph|8 years ago|reply
> 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.
[+] [-] joshontheweb|8 years ago|reply
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.
[+] [-] lorenzorhoades|8 years ago|reply
[+] [-] icelancer|8 years ago|reply
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.
[+] [-] dorianm|8 years ago|reply
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
[+] [-] koolba|8 years ago|reply
[+] [-] pjungwir|8 years ago|reply
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.
[+] [-] danudey|8 years ago|reply
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.
[+] [-] LunaSea|8 years ago|reply
[+] [-] logvol|8 years ago|reply
> 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.
[+] [-] th0raway|8 years ago|reply
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.
[+] [-] ams6110|8 years ago|reply
[+] [-] koolba|8 years ago|reply
I can understand an async mode of updates being partially behind but two days seems excessively laggy without a business reason for it.
[+] [-] hkarthik|8 years ago|reply
[+] [-] daxorid|8 years ago|reply
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?
[+] [-] colmmacc|8 years ago|reply
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.
[+] [-] scrollaway|8 years ago|reply
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.
[+] [-] wpnx|8 years ago|reply
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.
[+] [-] icelancer|8 years ago|reply
Err... we push seven figures a year through Stripe, and we don't do this.
[+] [-] rtpg|8 years ago|reply
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.
[+] [-] Cakez0r|8 years ago|reply
I think you answered your own question!
[+] [-] scrollaway|8 years ago|reply
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).
[+] [-] a13n|8 years ago|reply
Stripe sells to businesses, they aren't gonna drive their bottom line off $10/mo.
[+] [-] Swizec|8 years ago|reply
[+] [-] netfire|8 years ago|reply
[+] [-] georgewfraser|8 years ago|reply
[+] [-] neovintage|8 years ago|reply
* 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...
[+] [-] teej|8 years ago|reply
[+] [-] laurencei|8 years ago|reply
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.
[+] [-] mmanfrin|8 years ago|reply
[+] [-] scrollaway|8 years ago|reply
[+] [-] erickhill|8 years ago|reply
So, what does this software actually do? My company uses Stripe and it is not immediately clear.
[+] [-] cocoflunchy|8 years ago|reply
[+] [-] gbrits|8 years ago|reply
[+] [-] ucarion|8 years ago|reply
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.
[+] [-] vijucat|8 years ago|reply
Stripe could have particular constraints that I'm not aware of, but it seems to an example of not-invented-here syndrome.
[+] [-] mygo|8 years ago|reply
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?"
[+] [-] pestkranker|8 years ago|reply
[+] [-] packetized|8 years ago|reply
[+] [-] adamballai|8 years ago|reply
[+] [-] johns|8 years ago|reply
[+] [-] jasongill|8 years ago|reply
[+] [-] chrisacky|8 years ago|reply
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)
[+] [-] 15155|8 years ago|reply
The SQL layer could probably just be an API client to the data they have already.
[+] [-] EGreg|8 years ago|reply
[+] [-] hughstephens|8 years ago|reply
[+] [-] whatthemick|8 years ago|reply
[+] [-] ram_rar|8 years ago|reply
[+] [-] alexchamberlain|8 years ago|reply
[+] [-] tresante|8 years ago|reply