I was very interested in something like this few years back. But, my quick research showed me that
(a) A company called Orbiscom (acquired by MasterCard) had patents in this space [1], and they are the ones behind Bank of America's ShopSafe and a few other such services offered by various banks.
(b) Almost all of those services (except for ShopSafe) are now discontinued. Which indicates that either users don't care about something like this, or that banks don't like offering something like this for some reason. Maybe that explains why nobody knows about MaskMe [2] etc.
I would be curious how Final guys are overcoming those issues.
The industry goes much deeper than that, and there are many vendors that also issue virtual cards via other methods. Checkout Wex & Conferma for a few.
A few big changes are happening on the backend of payments that we also plan on leveraging. See this spec if you want to learn more about them: http://www.emvco.com/specifications.aspx?id=263
Can we please have a rule against posting paywall links? I know we can find a cached version or search on Google or whatever, but it's still frustrating!
I am not asking for a work-around to access WSJ articles. I'm asking HN to consider blocking domains that force users to pay money to access their content.
> Can we please have a rule against posting paywall links?
Can we please stop already with the complaints about paywalls? Diligent, thoughtful journalism doesn't happen for free; it's great when HN links can be read for free, but paywalled links shouldn't be second-class citizens.
> Diligent, thoughtful journalism doesn't happen for free
A free to use website (with ads) doesn't mean the journalists aren't payed. Most of the time, they are.
Generally, there's nothing wrong with payed websites, but it makes it a bit frustrating for people at a discussion board for web articles. Especially when there are users who really can't afford them (from countries with less income than North America or Europe) and the same information is available on free to use websites.
I disagree, firstly on your call to stop complaints. Anyone should be able to question the status quo. Secondly, I disagree on treating paywalled links the same way "normal" links are treated because this breaks functions of the web. I dislike sites that allow indexing but hide the content from users of indexing sites, like scribd, which contents can be found on a search, but is behind a paywall when you try to access it. This breaks search engines, and this breaks HN. This practice breaks other sites and uses them as advertising spots.
Paywalls might arguably break Hacker News (although that's debatable) but they certainly do not break search engines. The job of a search engine is to index all content. It makes no guarantee that you will not have to pay for the content it indexes. It only claims that the content it finds is relevant to your search.
WSJ is an exception - you can always google the title to get a free copy. Also - they broke the news a good 2+ hours before any other sites - so they were the only source.
I have wanted to use Mixpanel for a while. But your product is very very expensive for a Startup. When we're trying to be frugal, there's no way we can justify spending $150 per month on collecting data on just 5,000 users (where 98% of them will be free-users). Your product becomes interesting to a Startup only if they won't have to worry about paying for analytics till they're really successful. That means many millions of data-points. Not 25,000 or even 500,000.
The only Startups that can afford your service at this point are the ones that have only paying users.
We circumvent Mixpanel's limited events early on and stayed under their free tier for as long as we could. This is what our setup looks like:
We collect millions of data points a month and save them on our servers. We do not use Mixpanel's SDK to collect these data points, but have written our own code for that. We save the raw data on our server, aggregate a bunch of similar events to 1 event and then push it to Mixpanel using their API. We heavily use event properties to send as few events to Mixpanel as possible.
This way we get most of the data into Mixpanel and can build funnels, etc. without any issue. There are some edge cases where we aggregated data is a limitation. But for those cases, we end up using the raw data that we store.
Not sure about your use case, but hope this helps.
That's precisely why we price on a per-user basis at Indicative (https://www.indicative.com) and not on a per event basis.
What you described is a lot of work to build and maintain and very brittle. We've had quite a few customers switch to our platform from Mixpanel that were doing the same thing - aggregating data or sampling.
The problem with either is that you basically blow up your user-level data (e.g. John Smith doesn't have the right activity history), you will miss potentially important trends that are statistically significant that only appear over time, and you limit the type of analysis you do by "property stuffing", particularly around cohorts and retention.
Same problem here. I recommend having a far higher limit on free users. Maybe you can also charge less if the growth rate of active users is less than x% per month. They won't have money to pay anyway without traction.
Surely WF's needs with YUI-fork (or any other similar library) will be limited enough that they'll need to hire just one or two developers. I don't see how they'll need to spend hundreds (or even tens) of millions of dollars to build a solid library. I don't think even Yahoo has spent that much on YUI in total.
IFTTT is at a great spot to bring simple programming & logic to non-programmers who just want to customize how they interact with technology just a little bit. Looks like Yahoo Pipes missed a big opportunity there.
However, the IFTTT homepage and WTF page are still too complicated for a casual visitor. The WTF page throws all these terms like Channels, Triggers, Actions, Ingredients, Recipes, etc instead of focusing on telling the visitor what they can do with IFTTT. The name (If This Then That) is amazing for explaining what IFTTT is. But, beyond that, they seem to be making things look more complicated than they need to be.
I completely agree - I don't necessarily know what better would exactly look like - but explaining the why as opposed to the what is a great place to start.
IFTTT really is not that complicated, it is something that many people realistically could utilize, even if they aren't very tech savy. Something as simple as a beginner mode which hides everything except complete recipes from the user might go a long way in appealing to a broader user base.
I've been using Dropbox with EncFS, and I feel foolish about not thinking of the fact that Dropbox has ongoing access to the encrypted files.
Would you recommend something other than Dropbox + EncFS as the best compromise for a file-sync solution that has reasonable security, a non-buggy client, supports block-level sync, is reasonably priced and "just works"? BitTorrent Sync + EncFS?
Can we please have a rule against posting paywall links? I know we can find a cached version or search on Google or whatever, but it's still frustrating! We're not talking about work-arounds.
Imagine what our reaction will be if someone posts a link to their own blog which doesn't allow visitor to read the content without paying $1. Even if they have a work-around like you can inspect element and hide the paywall popup.
The WSJ's article isn't a summary of The Information's original story. They confirmed the report based on their own sources, which is completely legitimate even if they weren't the first ones to break the story.
The site is called Hacker News, not Hacker Support broken business models that keep content off the open web but get traffic by faking it.
For the majority of readers here there is no news at the end of that link, just and advert for the WSJ's paywalled services. It's effectively spam for most of us.
The submitter can find another outlet and submit that. Submitting a paywall article is like submitting an item with no link at all, with text content "google it."
Definitely appreciate this a lot. I am sure he gets it reviewed by a few people who are closer to the metal.
This is a great way for him to be on top of all the technology that goes in his extremely technical company. Moreover, him understanding the details from the engineers, then writing a blog post about it, and then getting it reviewed by the engineers ensures that the blog post will be understandable for the customers, who are likely to be at (or slightly below) his level of understanding of this technology, not the engineers who actually implemented the thing.
This may be a good place to ask this: Does anyone have experience using Flurry Analytics and Google Mobile App Analytics in production? We're comparing the two, and would love to get opinion from people, who have used them in production, about the not-so-obvious pros and cons.
We used Flurry last summer, but ended up switching to Localytics who we've been very happy with. The main reason was real-time data (which was really important to us since Flurry was lagging by several days). The nicer UX and faster customer support are big pluses as well.
Happy Flurry user since '11. Not all reports need to be realtime, in fact most don't. Their event tracking is solid and the reports are great for getting info at a glance. Doesn't hurt to use multiple, but I've always been content with Flurry's suite.
There's no comparison, from my experience, Flurry is a lot better and more useful. But, I'm not a google analytics guru so its possible google is better if you know how to use it.
I've been using Flurry for the past year and thinking of switching. I don't like the way Flurry presents data on their platform and the website is really slow.
Flurry's definitely way better than GA for getting set up in spite of all the issues you'll run into at scale. Please give us a call once you hit that though.
I've used the iOS SDK for both in beta deployed apps, and prefer Flurry due to their more flexible custom events. With Google, a custom event has four fields (string, string, string, number), limiting how much you can capture for an event. Flurry allows up to ten, with data types of your choosing.
(a) A company called Orbiscom (acquired by MasterCard) had patents in this space [1], and they are the ones behind Bank of America's ShopSafe and a few other such services offered by various banks.
(b) Almost all of those services (except for ShopSafe) are now discontinued. Which indicates that either users don't care about something like this, or that banks don't like offering something like this for some reason. Maybe that explains why nobody knows about MaskMe [2] etc.
I would be curious how Final guys are overcoming those issues.
[1] http://en.wikipedia.org/wiki/Controlled_payment_number
[2] https://www.abine.com/maskme/features/cards/