Hacker Newsnew | past | comments | ask | show | jobs | submit | breakthesystem's commentslogin

Hi HN, my new project AppTelemetry has finally entered open beta. AppTelemetry is an analytics service for privacy-conscious iOS or web app developers that helps you improve your product by supplying immediate, accurate telemetry data while users use your app. It's light-weight and easy to use, and it never ever stores any personally identifiable information, choosing instead to give you all the info you need through statistical analysis.

It's completely free during the beta, and will remain free for small and medium sized apps. Large apps (with a huge number of signals per month) will later pay less than 10EUR per month.

I'd love for you to check it out, try if it's something that fits into your workflow, or comment on what you like and don't like!


Hey, this looks interesting! I realize how essential telemetry is in the information age even for sizable open source projects. For example, Firefox does a lot of privacy preserving telemetry to provide insights on metrics such as how many people are utilizing a given feature.

Any open source project which helps do telemetry in a private manner is a good thing in my books.

I'm just curious, who exactly is your target audience/market with this project?


At a cursory glance, http://featureflags.io/ seems to only be a marketing page for LaunchDarkly. I don't see any other server advertised there, and it is obviously built by them. I didn't search that long, but I didn't find a submission link either. So ¯\_(ツ~)_/¯


Thanks for all your kind words and improvement suggestions! I've started cataloguing them into [tickets on github](https://github.com/ablator/ablator/issues). Feel free to add more or extend existing ones! :)


This is actually self hostable. Just get the newest source from github and build yourself a docker container :)

Or you can get it hosted if you don't want to worry about changelogs and the like.


Awesome, thanks for the tip!


Thank you for the encouraging words :)

Do you have specific improvement suggestions for copy, or should I just get some people who are good with this and ask them for help?

The all users thing is a nice idea. I'll have to think a bit about how it implement this.


Two things. In response to your request for suggestions, maybe a little more explanation about how it works. For example, does my code have to manage the dispatch to the "flavor"? Or is this in the client-side ablator libraries.

Second, this is a feature question or suggestion. Does the client side library track exceptions or have a way to report errors in a particular "flavor"? Or how does one decide to increase the roll out coverage of a new feature?


Thanks, I'll clear that up in the copy! But in short, the ablator server decides which user gets whic flavor. Right now, this happens randomly, but I'm thinking of adding more rules in the future.

Exception tracking is not built in, but you could use something like sentry, and send the flavor value as metadata.


For copy.. an example

"Ablator is a Service that enables you to roll out functionalities in a controlled way, and perform good A/B testing."

To: Ablator enables you to roll out features in a controlled way and measure their impact.

I'm sure this can be improved and once you gain traffic you can use your own service to optimize it, but I like to use the language my audience uses (features v functionalities) and strip out unnecessary parts


Good example! I'll definitely work some more on that


I don't mean get all flags for all users -- I mean your API should return the status of all features for a given user.


Yes! The challenge is, I feel like it'd be a preferable to return all fearures for a given user within an Organisation, as opposed to all features, period. I don't know why I feel that way yet... maybe a security risks? Guess a username, find out about a new secret feature from some Organisation using ablator.


Surely you have an API key?


Not right now, since the functionality ID is just as effectively. But switching to API keys is probably the way to go, and I'll do some work on that over the next days.

Btw, I created an issue for that at https://github.com/ablator/ablator/issues/95


Depending on your target platform, you might not have as much control over your releases. On the web, it's easy, but on e.g. iOS, it gets a bit harder.

I agree: like error reporting, it's not a hard, unsolvable problem, but it's a problem I had a few times and decided, why reimplement the wheel I could create a helpful open source solution?


That's a cool idea. Any ideas how you'd want to distinguish between cohorts?


If I could set arbitrary key/value on both users and features, that should be enough to make it work.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: