Re: [syndication] Accounting for aggregated views

[Dimitri Glazkov <dimitri.glazkov@gmail.com>]

On Fri, 25 Jun 2004 18:54:32 -0400, Bill Kearney <wkearney@syndic8.com> wrote:
> 
> A bit long and decidely rant-ish but I'm open to debate...

I rant, you rant -- we rant :) What else geeks are supposed to do
Friday night? Besides, I have to use up some of my "list newbie"
melodramatic credits.

By the way, if I skip anything, it's because I am agreeing with you
and don't see a need for further discussion.

> > Yes, this is a possible solution. But don't you think it solves a
> > generic problem with a specific implementation? In other words, there
> > is no standard way of implementing this behavior. Is there?
> 
> There doesn't need to be a standard behavior and possibly having one would be a
> bad thing.  Think about it.  If there was a standard way to force such things on
> users then there would surely come a way to break it.  By using plain old URLs
> in site independent ways you're eliminating at least one part of the risk.
> Sure, the "word could get out" about a feed stooping so low as to use such
> things (I'm kidding, of course) but it wouldn't make it "easy" for aggregators
> to take wholesale steps at skirting around the attempts (aka newsmonster).

Of course they will break it. RSS is a standard way to retrieve
syndicated content and there are some invalid feeds and dyslexic feed
readers. However, I don't think you are advocating independent
implementations over standard ones, so I'll let this one go. Besides,
there's better stuff down below.

> > > To the folks that say they hate using teaser feeds then my response is then
> > > you'll have to live without having more detailed web statistics.  This is
> also
> > > how I respond to the folks that refuse to play along with RSS unless they
> can
> > > get the stats.  

-- skipped --

> > But why? Why do they have to live with that? If there is a real need
> > for something, why not attempt to address it?
> 
> To serve whose ends?  The content providers?  Given the tremendous amount of
> content that's emerging, it's utterly ridiculous to think the consumers will
> tolerate the intrusions on their privacy when they can just get the content
> elsewhere.  Serve US, the consumers, or you're toast.  Well, maybe it's not
> quite that extreme but it's certainly not going to slide toward better serving
> the needs of the publishers.

Good question. I think you've hit the nail on the head here -- if
there's anything out there to keep track of aggegated views, it should
probably be transparent and optional. Kind of like what bloglines is
doing.

> > So, what I am trying to do is start a discussion on the "right" way to
> > account for aggregated views.
> 
> And I'm saying that without a whole lot more explanation as to why the users
> should put up with the burden it's just not going to happen.  There's an awful
> lot of side-band communication that would have to take place.  Right now it's
> one request.  Pull the feed and read it to your hearts content.  To start
> pushing back usage data would require a whole other level of effort on the
> reader side of the process.  The reader (this being a portal or a user client)
> would then have to start keeping track of usage.  Then that data would have to
> get pushed back up to the consuming site.  The consuming site would also,
> presumably, have to start keeping track of it.  And to what end?  Making the
> advertisers happy?  Pardon me if I'm less than motivated.   And don't think
> you'll be able to get away with just pushing up a simple integer.  I'd bet a lot
> more would be demanded.

Yes, it probably would.

I think a very complex part of this problem would be figuring what
exactly constitutes usage statistics. From what I saw, CDF pushed up
raw logs. That's a bit much, don't you think?

> Consider what a pain in the ass it would be for an RSS reader on a cell phone to
> push this data back to a site.  The SMS bill would be astronomical.  Try
> explaining THAT to an outraged cell phone customer.  Likewise, consider the user
> on a detached laptop or one that's behind draconian firewall configurations.
> What should those be using?  Why should their reader program have to jump
> through extra hurdles to collect and deliver data back to the source?  What's in
> it for them?

I am not sure if I want to worry so much about individual readers. I
think the protocol that I am envisaging should be based off of a trust
relationship between a syndicator and an aggregator server. For
example, my company subscribes to Syndic8 to provide intranet-based
newsfeeds using an aggregating server. Would you would like to hear
back from this server about what's being read and viewed?
 
> Now, someone that wants to start publishing feeds and offering cash back for
> usage is more than welcome to try.  I'd daresay there's potential in it.  But I
> can also imagine just how thorougly hackable it would be.  Heh, the script
> kiddies would have a field day gaming the numbers.

Oh, yeah. Anything that may involve uploading data to a server would
be a hot item in the underworld. That is why our protocol should
provide for security.

What is y'alls' experience with aggregator servers? You are one, but
do you see (or see the potential of) any of the cascading
relationships with smaller or parallel services?

:DG<