Cross pollination with other tech community?

Advocacy
1

First Sangalli's idea. Take Tech Share 2.0 meetup for example, their previous talks span quite a range of areas. Their previous 3 talks are about Design, Machine Learning, IoT respectively:

http://meetu.ps/c/3C8Ff/tkbg1/d

My thinking presently is to explain tokenisation (t10n) to the tech community geniuingly interested in achieveing something in their area with blockchain tech. To be pracitcal, what are the tokens that a website owner would want to accept (its use) on their website? It's easier to talk about a practical case from there.

2

Starting with some ideas...

From my experience as a freelancer, every website owner, wants in one way or another:

  • Acquisition
  • Conversion
  • Retention ("return" for content, "repeat purchase" for shops)
  • Brand Strength/Awareness

There's a million ways to do the above, and the keywords might change depending if the website is a software, blog, marketplace, shop, etc. But these are some pretty standard needs:

  • Web owners want user meta-data for re-marketing (Facebook pixel, Hotjar, etc)
  • Web owners want direct user data, like email/phone number (for sales, build lookalike audiences and re-marketing)
  • Web owners want commitment, through sign-up or purchase (easier to keep them returning or purchase again after that)

Thinking tokens, then...

  1. Profile Token — Includes email, name, personalisation, etc. Single-click newsletter sign-up (no typing), single-click sign up.
  2. Data Permission Token — Like a different form of ad-blocker, enables permission to use information, in exchange of special content, etc. Smoother than current sign-up/whitelist flows for content sites.
  3. Payment Data Token — like a form of Express checkout, or see the UX https://www.nate.tech/ is doing
  4. Notification Permission Token — like a subscription, get the latest in exchange for access to attention
3

Very good feedback thanks. To convert that into action, I'm thinking:

  1. Using the above token as example to do a workshop with web developers to get feedback and ideas; this can be done without doing additional projects.

    1. The proof of email address is part of the Alice-send-token-to-Bob project, whatever created there is demonstrable in such a workshop too; is it an advantage, that the email attestation can be used to create an authorisation, which the website can keep to prove to GDPR authority or email gateway (otherwise they might need to provide a "click to confirm subscription" button)?
    2. Other concepts you listed can be explained instead of demonstrated.

  2. As to whether or not we do a project based on the 4 types of tokens you listed, we will learn from the feedbacks? (I am especially interested in the concept of the nate app you mentioned - will try using it for a while to see how applicable the idea is).

4

is it an advantage, that the email attestation can be used to create an authorisation, which the website can keep to prove to GDPR authority or email gateway (otherwise they might need to provide a "click to confirm subscription" button)?

Well, GDPR doesn’t actually require double opt-in, just express consent which can be in the form of clear language in a landing page. Why marketers will generally adopt “confirmation” emails is that it leads to better lists.

Is it an advantage?

I see the value to be for marketers. In email marketing, there’s…

  • Single Opt-in (SOI), which means when a user subscribes to a newsletter, he only needs to insert the email in the website. Conventionally, this results in more conversions but the worse quality.
  • Double Opt-in (DOI), which means when a user subscribes, he inserts his email on the website, and then receives an email to click a “confirm” button to finish it. This results in less absolute numbers but better list quality.

Email Attestation Subscription (EAS) proposes:

The user comes across a subscription inline box and sees his email already there. He clicks “Yes, subscribe” and he’s done. He might get an in-page confirmation pop-up.

This is SOI conversion, with DOI quality advantages. Marketers will focus on conversion and list performance, and users would focus on control and privacy, and there are several measurable benefits:

For the marketer:

  1. Conversions: In-page confirmation instead of email, in particular with mobile flows
  2. Conversions: No requirement for reCAPTCHA (it's a real person)
  3. Conversions: Flow options to subscription or purchase
  4. List Quality: Attested email on a website means no spam or CAPTCHA requirements
  5. List Quality: Attested email on list reduces no hard bounces or fake emails
  6. Legal: Fulfill CAN-SPAM, CASL and European requirements

For the subscriber:

  1. Control: Control of all email sign-ups, quick unsubscribe if possible
  2. Security: If email is encrypted, then its not subject to data breaches or having his email sold to weird lists
  3. UX: Better subscription flows on mobile

For delivery platforms (e.g.MailChimp):

  1. Better throttling control
  2. Privacy and security promise
  3. Simplified code, no need for honeypot

Would there be adoption?

I think it depends if it delivers on the promises: Is the conversion better and is the quality good? If I promise “SOI conversion, with DOI quality” I think any marketer would be interested.

There's usually a division between SOI and DOI defenders, but I think either would be happy to try because marketers are all about testing. The promise seems good. Websites will happily plug it in, and then decide.

To really be conclusive would be to also provide volume, e.g. users that adopt it. Would users take it? Perhaps starting with crypto-related channels.

Users: Do I need an app for this? An extension? Do I need to install anything? How do I do my first attestation?

Websites: Is this an inline snippet, or a complicated solution? Can I adapt this to my needs? How does it look like in terms of UX?

Platforms: Does this improve my overall delivery? Can I use this to attract more customers?