Thanks for this in-depth analysis. I guess we're in company c', though we may borrow a page from the 'just sign them up' scenario for clients who do not have a gb account.
Cheers, On Sep 23, 2:42 am, Celebird <[EMAIL PROTECTED]> wrote: > i don't think there is a concept of a "bona fide" aggregator; > but google does use the term for a multi-client account as a > way to handle multiple domains and display-names from under > one account; that's google's working-definition. > > i wouldn't assume customers require google-base accounts; > again, if i look at the ecrator model none of their > customers require google-base accounts nor does ecrator > require for themselves a multi-client account -- because > all their data, from all their customers, is under one > domain and name -- yet all client data is "aggregated" > onto google-base. > > having separate client domains is yet another model -- > customers may or may not require google-base accounts. > > one point of authentication is to allow your application > to work on behalf of a client without you knowing much > about the details of that client such as their gb-email. > > i suppose there are many reasons to become an aggregator -- > i tend to classify them based on use-case or feature-set. > e.g. > (a') client data on my site offering google-base > as an advertising mechanism but without clients > knowing anything about google-base or needing a > google-base account: > your domain; your name; their data on your domain. > > (b') clients own a website and data but don't want to > understand google-base; same scenario as above except: > their domain; their name; you can create accounts on their behalf; > this is the classic "aggregator" as defined within google-base. > > (c') clients own a website and data and have a google-base > account but cannot or choose not to understand google-base > but want to have some control over their items or feeds -- > so, their domain; their name; their google-base account; > your application; they use your application to create better > faster data with richer content or more easily create feeds. > > (d') same as above but your application simply creates a feed; > this requires no google-base interaction whatsoever -- you can > simply create feed-files from websites and the client does the > rest, including posting the file; no google-base api is required; > mainly database work and understanding of attributes and formats. > > the primary reason for becoming an aggregator is probably > to make some job easier for clients or to create rich data > that allows clients to rank better within google-base. > > many "aggregators" of the first type feed their data into > other comparison-shopping-engines besides google-base; > some have value-added features such as seo analysis > or integrating generic seo with comparison-shopping. > > others stray away from the product item-type altogether > and offer aggregation for housing or vehicles for example. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Base Data API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Base-data-API?hl=en -~----------~----~----~----~------~----~------~--~---
