ENS Affiliate Marketing - Affiliate Program

I’m worried that a misleading UI will be created, where prices may be +10% for some people and not others, inviting all sorts of confusion and questions and support tickets and jabs from UD and other detractors (and rightfully so).

I’m open to your ideas, but how do you propose we address the UX and optics?

I also want to remind everyone that ENS is not “a business”, it is a public good.

1 Like

Regarding this concern:

  • When on the ENS site, or any site that was ethical,
    the price would always be the same $5/Name (5-char+)
  • When on any other-site, which was an unethical-site,
    the price would always be btwn 10% lower, and no reason why it couldn’t be higher.

Now, ask yourself: Does this happen ANYWHERE else in Web3?

  • Yes: This happens with NFTs Sales, and
    the skirting of royalties via sites like NFTtrader.

When royalties are gone around, is the user perception that NFT prices were +10% less?

  • No: Users know they are cheating the system
    (And the NFT creators) by saving money.
  • There is no misleading UI or confusion why it is cheaper–Everyone is very clear:
    It’s cheaper because users are not respecting peoples royalties or the public good.

Regarding this concern:

  • It is interesting we have to say this, but it is still important:
    every organization & industry has “business & marketing best practices”.
  • Every corporation, organization, government, non-profit, & DAO
    has best practices, including “business & marketing best practices”.
  • In philosophy, economics, and political science, the “public good” refers to
    what’s shared & beneficial for all or most members of a given community–
    And Public Goods have “business & marketing best practices”.
1 Like

Yep fair enough! Just wanted to remind everyone… :laughing:

Okay, so you’re saying even if they access the site without any referral link, they would still receive the +10% price quote?

In that case, does the extra 10% just go to ENS?

Yes, (to the DAO), exactly.

Just think how Amazon works:

  • When you buy via an affiliate link (or not) the price is the same regardless.
  • When an affiliate helps make the sales, then they are rewarded with a percentage-cut.

My concern is that in this situation we know users would prefer to have the choice to opt out of a referral fee and keep the 10%, but we are not offering it to them. That’s not a good user-centric design choice. There’s not really a parallel to Amazon etc, because they don’t let the user keep the referral fee due to the permissioned nature of their system.

Okay, as long as the UI is consistent and everyone sees the same prices for everything then that’s fine. Apologies, I don’t think I 100% “got” your proposals earlier.

I think I mostly agree with your counter-argument about self-referring. With an open system, anyone can self-refer to themselves and get the discount of course. And as you say, anyone can do that, but most people probably won’t, it’s an extra step.

Yes, somebody will setup a “cost-plus” UI, and maybe that’s okay, it won’t be the official UI.

However, someone else will also create easy-to-follow documentation on how to self-refer yourself and get the discount. Is that a concern, you think? Because at the end of the day the self-referral might just be… a single transaction? Or it might even be an off-chain easy signature, not sure.

With regard to:

  • I do not agree 100%, and I have already addresses this with comparison to NFTtrader & NFTs;
  • The majority of users: 1. won’t go out of their way to screw the system, and 2. will be shamed for hurting Web3 creators (and all data is onchain).

With regard to:

  • There are always some concerns, much can be mitigated,
    but there will always be ways to game ANY system, somehow.

  • Nevertheless, aren’t we talking about Public Goods?
    Web3 will not work if we can’t support independent users work;
    (Just like NFTs would falter if the system for royalties fails, or does not evolves.)

At the core, we have two options:

  • Option #1: Create an open affiliate-system
    that rewards creators, but can be abused.

  • Option #2: Do not create a system that rewards creators,
    and then, no abused can occur with the system that doesn’t exist.

1 Like

Yeah, there’s no perfect solution. An open system almost necessarily means people will game it.

If others don’t think that’s a big concern then I’m fine on that point as well

1 Like

Why not base a referral system on a top x% of referrers, or referrers getting above x registrations per time period? It would need to be managed to some extent, but not nearly as much as a fully selective registry/list.

  1. Essentially means that users wouldn’t be able to self-refer (unless they were registering a large amount of names).
  2. Disincentivises anyone from forking the front-end to make names X% cheaper, since payments would be made in bulk to a single wallet so the gas fees of sending referrals back to each wallet would outweigh the original fee most of the time.

Still not a great solution but I feel like there really isn’t one here.

1 Like

In my opinion, mobile is the where 99% of all users will get a name in the future. An affiliate program works perfectly for mobile. The convenience makes any small fee irrelevant, and it encourages this practice.

You could write a smart contract that acts as a ‘referrer’ and allows anyone to claim their referral fees back. It’d get good bulk rates if everyone used it!

If you register a 5+ char name for 10 years, you’d get $5 back at a 10% referral rate. I can’t imagine that the smart contract would be able to let anyone claim without gas fees taking a significant chunk, effectively making it useless for most people. If the referral is also being applied to the premium period or <5 char names though, that’s a different story.

1 Like

That’s a fair point. It’d be more practical for 3- and 4- character domains, but may still not be cost-effective.

2 Likes

Ok, this is what I am imagining right now. I think this will work.

  1. Create a mapping of addresses to addresses for the beneficiaries for each account.

  2. Crete a mapping of addresses to balances to store the balances for commissions.

  3. Create a Register function with a beneficiary so that the beneficiaries mapping can be set at the time of registration.

  4. Allow the user to change the beneficiary in their account settings, including to themselves — this is also a great opportunity to create a list of public goods that the user can chose. I would not show the beneficiary on the first checkout page, as I think this will disincentivize the use of the affiliate program for referrers.

  5. Create a claim function to transfer commissions at any time.

I think this will add a minimal amount of gas to an initial transaction, with just two mapping updates. Any secondary transactions will have only one mapping update.

I think it is also possible to save a lot of gas in the future by phasing out the old registrar and only using a V2 NameWrapper, which with the new upgrade code coming in V1 NameWrapper makes this possible.

2 Likes

Wouldn’t intentionally obfuscating these incentive payments be suspect? Especially if the motive is to prevent the user from making the choice that we acknowledge they would likely make if fully informed?

Would we expect lots of large advertising focused entities to set up claim accounts and drive traffic through advertisements (Google AdSense, Media[.]net, PropellerAds, etc?) There would be no accountability on the messaging that ENS is subsidizing through these hidden incentives.

@AvsA’s transparent model mitigates some of this, but even that might not be received well when users see that they’re funding web2 advertising companies.

Final thought - any 3rd party is free to build a value add layer on top of the existing ENS registration system and charge whatever fee they wish.
The ENS DAO could instead continue to focus on encouraging these value add layers that incorporate ENS registration into other business models that would ultimately be more additive to the user experience. Rainbow is a fantastic example.

2 Likes

Affiliate System:

  1. User clicks link to purchase an ENS name.
  2. The ENS Name costs $5/year (5+ Char).
  3. Upon checkout the final cost is $5/year.
  4. ~10% of the cost goes to the referral.
  5. There is not am easy way to prevent this, unless the user clears their catch.

People who create content & code need ways to generate revenue for their work.

If content & code creators succeed in getting the user to click the link to ENS, and the user buys via the ENS contract, then the content & code creators should get compensated. Period.

  • Why are we building systems to hurt Web3 creators?
  • Why do we want to make it easy to hurt content & code creators?
  • Why should it matter if the content & code creator is getting paid, since they did the work to get the users to the ENS site?
  • The talk about hurting the content & code creators is counter intuitive, and if it is built that way, then most will not use this affiliate system; since the risk is too great a risk for loss, for the content & code creators time and resources.

I understand there are cases where we may want to “police” the system, but this is an issue across all decentralized products. Are we running a company or a protocol?

I love how dedicated & thorough the coders & engineers are here,
but it seems few here respect business & marketing for a healthy ecosystem.

1 Like

We’re not.

Why do we want to make it hard for users to make an informed choice about where their money goes?

2 Likes

Making it easy for Web3 creators “to be denied value-reward for their hard work” is a bad system.

  • The referral fee is not going to a random organization,
    and is not designated by the DAO, or a centralized organization.

  • The referral fee would be going to the person/organization,
    whom did the work to get a user to facilitate the ENS sale, on the ENS contract.

If the affiliate system blocks the Web3 creators value-reward for their hard work [content or code that brought visibility & traffic to ENS], then this system is no longer a real affiliate system [since a percentage of those users lead to sales, and a large percentage of those sales will always deny the affiliate when giving the option]; and then the point is lost, and the system will fail meeting meaningful adoption or its objectives [of brining visibility, traffic, & sales to ENS].

Again, this comes back to who we have a duty to serve first: end users, or platforms. I’m firmly of the belief that the ENS app ought to serve users’ best interests first, and it’s not in users’ interests to make choices for them without them being able to change those decisions.

5 Likes