Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-personalized recommendations #50

Open
jameysharp opened this issue Aug 4, 2020 · 0 comments
Open

Non-personalized recommendations #50

jameysharp opened this issue Aug 4, 2020 · 0 comments

Comments

@jameysharp
Copy link

jameysharp commented Aug 4, 2020

I like that this spec covers personalized recommendations, but I think media feeds would also be useful for non-personalized suggestions of media related to the item which the visitor is currently looking at. This is partially addressed in the current draft by the case where there is no "member" person declared, but a number of use cases are currently precluded.

First off, as issue #9 discusses, the restriction of a single media feed per origin prevents per-item recommendations. A publisher might well want to have a separate non-personalized media feed for every page, or share the same media feed across only a portion of their site that's logically related.

User agents can do a lot with that information while preserving privacy. For example, recommendations which have appeared in multiple media feeds, perhaps even across different sites, might be given more weight. Doing so doesn't reveal to any publisher that the same person has seen that recommendation from multiple places. (edit: In fact, I think this usage mode is meaningful even in private browsing/incognito mode.)

Some of the use cases in the spec don't appear to me to benefit from personalization at all. Everyone who has just watched episode 5 of a TV show will presumably get a recommendation for episode 6, regardless of what else they watch.

I'm guessing non-personalized feeds won't change nearly as frequently as personalized feeds, to the point where it might make sense to only refresh the feed if the user visits the page again. (Publishers should be encouraged to use appropriate cache-control headers too.) Since that policy doesn't leak any additional information to network operators, I think it could be enabled without any user interaction, making this spec more valuable to publishers.

I'd like to see this spec be usable from things like Atom feeds to indicate media that the publisher recommends for followers of that feed. Again, in that use case, each Atom feed may have a separate media feed associated with it.

Another use case is the moral equivalent of "blogrolls": Someone might want to attach to their personal web site or social media profile some recommendations of media they like and think other people should see. Media that my friends deem worth recommending has decent odds of being media that I'll like too. But most people don't control an entire origin so they wouldn't be able to use this spec as-is.

If the user agent can tell before fetching the media feed that it isn't personalized, then it can also avoid some privacy concerns by not sending any cookies with the request. (edit: And as best I can figure, that's the only reason why a media feed is required to be at the same origin as the page that links to it, right? I think a publisher should be able to delegate recommendations to a third-party service.)

For all of these reasons, I'd even suggest making non-personalized recommendations the initial focus of this specification. Let the user agent combine multiple media feeds to provide privacy-preserving cross-origin personalization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant