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

use cookies to figure out who gave a one click thanks #147

Open
GoogleCodeExporter opened this issue Mar 20, 2015 · 0 comments
Open

use cookies to figure out who gave a one click thanks #147

GoogleCodeExporter opened this issue Mar 20, 2015 · 0 comments

Comments

@GoogleCodeExporter
Copy link

[copied from an email thread]

Right now if you send to a group the thank you is anonymous because we
don't know which of them clicked the thank you link.  Since we are
sending one email to a group, we can't give each of them a different
identifiable link to click.  But since clicking the thank you link loads
a page from the feedme site, consider the following hack.

1.  When a mail goes to a single user, put a distinctive url in the
thank-you note (or just remember who it was sent to)
2.  When that thank you note gets clicked, deposit a cookie identifying
the user onto their browser
3.  In the future, check for the identifying cookie when someone clicks
a thank you link.

However, what should we do about email lists, like
[email protected]. What happens if I click thank you from a
haystack email (assigning me a haystack identity), then I click thank you
from an email sent to [email protected]  and another user (so the
browser uses my haystack cookie  identity)? I guess if multiple users who
have already been identified clicks thanks from the haystack email, we
could determine that it's a list, but that relies on accurately identifying
people first. Also, keeping track of email lists may be tricky to implement.

Let's suppose we ignore the problem.  I send a fm to haystack-current
mailing list and someone thanks and gets a cookie associating the
browser with haystack-current (we can think of the cookie as just
containing the unique recipient email address).  so in the future, when
they thank, we can send "haystack-current says thank you"!  Not
terrible.  More complicated is if we _also_ deposited a cookie on that
browser for a different fm addressed to the single user of that
browser.  Now we have two different email addresses cookied with this
browser---how do we know which one is a more "specific" personal
address?    Especially since both or neither might be (one person can
have two email addresses, or they can be on two different mailing lists).

We do have a heuristic: if two browsers clicked thank you on an FM that
went to one address, then it must be a mailing list.  So, we can keep a
blacklist of such mailing lists and ignore cookies from them.  Note that
we _cannot_ use this heuristic if two _different_ FMs to the same
address produce thank you clicks from two different browser, because it
is possible that one user is using and thanking from two different
browsers.  However, I think we can ignore the possibility that one user
is forgetful and says thank you for the same FM from two different browsers.

So: if two browsers thanked the same single-address FM, then the address
is a mailing list.
Otherwise, should we just use the most-recent email-cookie on the
browser?  Or should we use all of them, e.g.
"haystack-current@csail/marcua@csail/[email protected] says thank you!"
Or a blend, say the three most recent email-cookies?

Minor point, but perhaps it is worth taking a mailing-list cookie if we
don't have anything else.  e.g., if the thanker has a cookie for an
address we've identified as a mailing list, and no other cookies, isn't
it better to send use the mailing-list id rather than nothing?  that way
if someone sends to two mailing lists they know which one thanked.

Original issue reported on code.google.com by [email protected] on 27 Apr 2010 at 6:44

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

No branches or pull requests

1 participant