Chronotope’s avatarChronotope’s Twitter Archive—№ 127,369

      1. …in reply to @ShortFormErnie
        ShortFormErnie swodinsky nicholasadeleon I thought some more about this and here's my theory: there's no central database of subscribers or links, but there is a central database of cross-device identifiers tied to a variety of emails used to catch fraudulent actions...
    1. …in reply to @Chronotope
      ShortFormErnie swodinsky nicholasadeleon If I were designing a dedicated system for emails I wouldn't want a central subscriber table, it's an unbound table row which is bad at scale. So instead subscribers are per-newsletter. Links also don't make sense to store b/c 99% of never get clicked, so that's a huge waste
  1. …in reply to @Chronotope
    ShortFormErnie swodinsky nicholasadeleon Instead, I'd store links w/clicks only *after* they've been clicked and sent through my system. I don't always need to tell users the individual subscriber who clicked a link... but I do need to know for my own systems, why? B/c I want to use it for fraud detection....
    1. …in reply to @Chronotope
      ShortFormErnie swodinsky nicholasadeleon So while there's no table of 'subscribers' there is a central table of 'users', emails that match to a mesh of device IDs and various actions that could designate them fraudulent. Then I can use that table to proactively boot bots or email fraudsters off my system...
      1. …in reply to @Chronotope
        ShortFormErnie swodinsky nicholasadeleon So my link needs to encode a whole bunch of data... the email of the user, the link itself, a bunch of prob standard decoration to allow for a/b campaigns, a newsletter ID, and a UUID for the user based on my anti-fraud table... b/c the links aren't stored centrally pre-click
        1. …in reply to @Chronotope
          ShortFormErnie swodinsky nicholasadeleon & maybe if I'm being really cheap, I only want to store information in my anti-fraud table if the user comes in from a new device, so I also encode all the known device IDs into there as well, so I only write to a DB when the device ID of the click doesn't match...
          1. …in reply to @Chronotope
            ShortFormErnie swodinsky nicholasadeleon This is still a ton of data that really should not get that long, but maybe I get lazy and use a bunch of hash functions instead of real encoding to cut down on execution time. Could be why? Could also be a bunch of extra data in there? You know what would be interesting tho...
            1. …in reply to @Chronotope
              ShortFormErnie swodinsky nicholasadeleon ...because you seem to be exactly the type of Newsletter Nerd to have multiple email accounts subscribed to the same newsletter ShortFormErnie ... if you do, does the same link end up longer when you are subscribed from a longer email?


Search tweets' text