+ Technically a live demo with a static dataset would be doable. [adds to Trello]
+ We think that $49 is reasonable given how powerful and flexible the service is. We can extend your trial if you are not convinced :)
+ Although in general I like freemium, I would feel slightly uneasy about sending my private data to a service that doesn't cost anything. Most free(mium) analytics services use the customer data for ad retargeting etc.
We are located at 7th and Market. We are always happy to grab a coffee at Sightglass that's nearby - feel free to ping me at [email protected].
Why aren't you a fan of trial periods? I much rather give it a shot before I commit to paying some money. In fact, I pass on many that don't have trials.
It's easy to talk the talk on a marketing website, a free trial shows the truth.
If they had a live demo, why would a trial be necessary? I think either a free plan or a really awesome demo provides the information and experience needed for users to make a purchasing decision.
I dislike trials because they require a credit card to even experience the product. Also, I hate having to remember to cancel before the trial period ends. The product should be compelling and exciting, and provide enough details and information that I am willing to pull out a credit card and commit.
I too would pick it up sooner if there was an (almost) free plan with some strict limits. That way i could use it in say a hobby project or something that's still in beta and figure out if it works for me before running up hefty costs right away. This is a product phase where usually stuff like hosting is free still (Heroku and such have free tiers) and $49/month is suddenly a lot in comparison.
We would be interested to explore feeding SnowPlow (https://github.com/snowplow/snowplow) atomic web analytics data into Bitdeli: potentially our SnowPlow StorageLoader (which currently feeds Infobright) could fire all SnowPlow events into Bitdeli using your Events API.
A couple of questions about your Events API:
1: does your Events API only support submitting one event at a time? Would be nice to bulk them up otherwise we're going to be creating 1000s of HTTP connections.
2: is there a reason why you pull uid up out of the event's JSON envelope, but not the event type? It's nice to have the event type outside of the envelope, because then you can know the expected structure of the JSON without having to look inside it. Just a thought - this is how MixPanel and Fluentd do it, and it's something we're moving to supporting for SnowPlow.
Anyway, have a think about feeding Bitdeli with SnowPlow event data and let me know if it's something you want to collaborate on! And keep up the great work in the meantime.
Feeding data from SnowPlow to Bitdeli sounds like a great idea.
1. It does, although it is an undocumented feature. You can send a list of events instead of a single JSON object to the Events API.
2. Bitdeli doesn't need an event type but it needs a user identifier. The event type is utilized with the data sources that provide it, like Mixpanel, but for instance our integration to the GitHub commits API doesn't expect that events contain a type.
A good starting point would be to create a super simple card that does something with the data from SnowPlow, like
Great stuff Vtuulos - I have signed up. Will probably take us a few weeks to get round to it as we have a few other releases which need to happen first...
I assume the backend is not on github? At least I couldn't find it. If that's the case I find the title misleading as the code that does the analytics work isn't shared.
The actual analytics work is done by the Python scripts which are open-source. See https://github.com/bitdeli or sign up to Bitdeli where you can see them in action.
The backend takes care of the plumbing: receiving and persisting data, scheduling scripts, managing computation nodes etc.
One thing I really like about this is the Python snippets alongside the chart, right there on the front page. It's unobtrusive but gives me an immediate feel for how script x could produce chart y.
If these aren't just stylized and you could make them live editable somehow you'd really be onto something.
Sounds great. It really says something about you that your product is able to stand out amongst all the billion analytics services out there.
It'd be like coming out with the best To-Do or Markdown editor app for iOS. :)
If I could make a suggestion, at some point you should create an analytics "gizmo" (or whatever you want to call it) gallery similar to http://bl.ocks.org/. You could even just parse the gist examples in Python and convert them to HTML/CSS/JS yourselves.
It would make it much easier to use and understand what can be done with your service. Not that I'm saying you aren't planning something like that. You already seem to encourage a pluggable approach, and what's easier than just going through a gallery and pressing an "install" button. Suddenly, you don't have to know any Python.
We'll definitely set up a public gallery of all the analytics widgets at some point. Since all the visualizations are produced by our Python scripts, you can check our documentation for all the available widget types:
Yes, definitely. The biggest issue with importing data from Google Analytics is that they have a pretty low quota for data export, so it is hard/slow to get all historical data out from GA.
+ Setup a live demo (allow users to fiddle with a demo and visualize the possibilities).
+ The entry plan of $49 seems a bit steep. Would a $29 plan be financially possible?
+ Personally, I am not a fan of trial periods. Either I find value in a product and am excited or not.
Great work though guys. Where in San Francisco are you located at?