4 ms·

Until services like this make their list of participating sites available, they strike me as amounting to a scam (regardless of how noble their intentions). If

Until services like this make their list of participating sites available, they strike me as amounting to a scam (regardless of how noble their intentions). If they have no partners, they still collect money, but have no one to give it to at the end of the month, so they'll have to keep it. I also have no desire for the entire subscription to go to a website I visit one time in a month because they're the only one participating. This is not necessarily a deal breaker, but I can't even make an informed decision without a list of participating sites.

saward 11y ago
If a subscriber doesn't visit any of our existing partners, then we don't pocket that money which was intended for websites. Instead, it's set aside as a fund for helping new websites to join, with a particular priority on those sites that our subscribers use the most. It may not be so bad if all of a subscriber's money goes towards a single publisher. We measure rates in terms of RPM. In such a circumstance, that single publisher is receiving an excellent RPM, and that gives us a good argument for convincing new websites to join. As you can imagine, there are many things on our to-do list -- but a list of participating sites seems to be frequently requested, so that needs to move up in priority.
- aluhut 11y ago
  A list of participating sites should be your absolute number 1 priority. Like, a call away. It is what I buy on your page.
jacques_chester 11y ago
> If they have no partners, they still collect money, but have no one to give it to at the end of the month, so they'll have to keep it. IANAL, but my suspicion is that the law of trusts will make this ugly, unless they write "we get to keep it" into their TOS. My own approach is to levy a fixed percentage and only pay out to participating sites. Readability tried to do the whole accumulate-for-not-participants as a way to try and create dangling carrots for publishers. It didn't work: it just tied up a bunch of cash, because finding out who to contact for a lot of websites is difficult. Add to that the relatively small amounts of cash held for a given website, spread across many sites, and it would've created a helluva mess. Disclaimer: I'm working on a competing product.
- kapad 11y ago
  Would you mind sharing the basic premise of your product. I'm also trying to create some partnerships for a similar product.
  - andy_ppp 11y ago
    I'm trying to do this too but I have a way in that doesn't involve too much capital... Maybe we should have a chat?
  - jacques_chester 11y ago
    Well it's the same general premise everyone stumbles on when they think about the problem for more than a few minutes. I call it "microsubscription". Pay a service a fixed monthly amount. That service follows you as you visit participating publishers. At the end of the month, the service divvies up your payment amongst publishers based on some kind of formula, typically proportional to visits, clicks, time-on-site etc. As I said elsewhere, the major technical problem has typically been that it's very easy to attack such schemes at the browser or at the publisher in order to create "visit multiplication". The scheme I designed relies on each of three parties -- a browser, a publisher and an authentication server -- providing independent verification of a particular network transaction occurring. Lashings of crypto, essentially. My first protocol design, the subject of an honours dissertation, was hilariously broken. My second design was a ground-up redesign and independently reviewed by a fairly decent cryptographer. I generalised the design so that any application protocol with some kind of control channel could be fit into the model. I intended to create a scheme where users could avoid ads, pay for sites they like, get an easy pass through paywalls, without cheating and without user trackability. None of this solves the fact that there are non-technical considerations that will probably be far more influential on the final outcome, barring a dramatic uptick in fraudulent activity souring the pot for my competitors. Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols.
    - Eridrus 11y ago
      > Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols. To defraud webpass etc, you need to be able to sign up as a creator, so if they're not interested in signing up the world (as most adtech players are), they can probably get pretty far just by partnering with reputable sites and forcing them to track and reveal which portions of their traffic is sourced vs organic. At some point they'll probably want to sign up the entire web too, but by that point they should be large enough to warrant buying the tech from a 3rd party fraud verification provider or build their own in house. I will say that, knowing what kind of fraud goes on in advertising, I am skeptical that a new protocol would do much besides adding an extra (static) hurdle for fraudsters.

saward 11y ago

If a subscriber doesn't visit any of our existing partners, then we don't pocket that money which was intended for websites. Instead, it's set aside as a fund for helping new websites to join, with a particular priority on those sites that our subscribers use the most. It may not be so bad if all of a subscriber's money goes towards a single publisher. We measure rates in terms of RPM. In such a circumstance, that single publisher is receiving an excellent RPM, and that gives us a good argument for convincing new websites to join. As you can imagine, there are many things on our to-do list -- but a list of participating sites seems to be frequently requested, so that needs to move up in priority.

aluhut 11y ago
A list of participating sites should be your absolute number 1 priority. Like, a call away. It is what I buy on your page.

jacques_chester 11y ago

> If they have no partners, they still collect money, but have no one to give it to at the end of the month, so they'll have to keep it. IANAL, but my suspicion is that the law of trusts will make this ugly, unless they write "we get to keep it" into their TOS. My own approach is to levy a fixed percentage and only pay out to participating sites. Readability tried to do the whole accumulate-for-not-participants as a way to try and create dangling carrots for publishers. It didn't work: it just tied up a bunch of cash, because finding out who to contact for a lot of websites is difficult. Add to that the relatively small amounts of cash held for a given website, spread across many sites, and it would've created a helluva mess. Disclaimer: I'm working on a competing product.

kapad 11y ago
Would you mind sharing the basic premise of your product. I'm also trying to create some partnerships for a similar product.
- andy_ppp 11y ago
  I'm trying to do this too but I have a way in that doesn't involve too much capital... Maybe we should have a chat?
- jacques_chester 11y ago
  Well it's the same general premise everyone stumbles on when they think about the problem for more than a few minutes. I call it "microsubscription". Pay a service a fixed monthly amount. That service follows you as you visit participating publishers. At the end of the month, the service divvies up your payment amongst publishers based on some kind of formula, typically proportional to visits, clicks, time-on-site etc. As I said elsewhere, the major technical problem has typically been that it's very easy to attack such schemes at the browser or at the publisher in order to create "visit multiplication". The scheme I designed relies on each of three parties -- a browser, a publisher and an authentication server -- providing independent verification of a particular network transaction occurring. Lashings of crypto, essentially. My first protocol design, the subject of an honours dissertation, was hilariously broken. My second design was a ground-up redesign and independently reviewed by a fairly decent cryptographer. I generalised the design so that any application protocol with some kind of control channel could be fit into the model. I intended to create a scheme where users could avoid ads, pay for sites they like, get an easy pass through paywalls, without cheating and without user trackability. None of this solves the fact that there are non-technical considerations that will probably be far more influential on the final outcome, barring a dramatic uptick in fraudulent activity souring the pot for my competitors. Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols.
  - Eridrus 11y ago
    > Google can get around this with their existing talent and technology for sniffing out fraud. The rest of us must make do with better protocols. To defraud webpass etc, you need to be able to sign up as a creator, so if they're not interested in signing up the world (as most adtech players are), they can probably get pretty far just by partnering with reputable sites and forcing them to track and reveal which portions of their traffic is sourced vs organic. At some point they'll probably want to sign up the entire web too, but by that point they should be large enough to warrant buying the tech from a 3rd party fraud verification provider or build their own in house. I will say that, knowing what kind of fraud goes on in advertising, I am skeptical that a new protocol would do much besides adding an extra (static) hurdle for fraudsters.