That makes sense, we would need to add a cap of % too cause we can’t giv the referal a min of $10 if the donation is only $1… Maybe its more like a range of the % of GIVbacks… like max 50%, min10% with a plateau at $10…
So if the donation gets $1 of GIVbacks, then the referring party gets 50 cents and donor gets 50 cents
If the donation gets $10 of GIVbacks, then the referring party gets $5 and donor gets $5
If the donation gets $20 of GIVbacks, then the referring party gets $10 and donor gets $10
If the donation gets $25 of GIVbacks, then the referring party gets $10 and donor gets $15
If the donation gets $90 of GIVbacks, then the referring party gets $10 and donor gets $80
If the donation gets $100 of GIVbacks, then the referring party gets $10 and donor gets $90
If the donation gets $110 of GIVbacks, then the referring party gets $11 and donor gets $99
If the donation gets $1000 of GIVbacks, then the referring party gets $100 and donor gets $900
50%, 10% and $10 are all variables we can play with, but thats a workable pattern.
Question:
How does the referral GIVbacks work? Is it like, they click a link to a project and if they donate to that project then GIVbacks get split for that one donation, and then if they go donate to another project, all the GIVbacks go to the donor? Or is it like all the donations that person makes that day or that round give out a referral bonus to the person designated?
@Griff Yes, I was thinking that it’s just for the initial donation, not the entire day or round, although we can play with that in the future.
For the calculations you mentioned, I think that could work. In that case, could we add this referral data to our standard GIVbacks calculation process @WhyldWanderer@renjer? For example, if for each GIVbacks round the tool gives us a list of all the referrals (their addresses along with the amounts), we then manually calculate how that affects each user’s GIVbacks and allocate accordingly from our end?
As opposed to user’s being rewarded from Chainvine or separately from GIVbacks, I think that would make it much easier for us to control.
Thanks @renjer! Sorry, when I said manually I meant in-house as part of our GIVbacks process (instead of having a third party calculate the rewards for us), so yes it could be automatically calculated from us.
I really like the proposal. I think this is a HUGE opportunity for Giveth’s growth.
I also appreciate the discount.
Regarding the exact process, I think considering most people’s first transactions in a new Dapp are low, just to see if it’s actually working. It might further incentivize our ambassadors to keep influencing more donations if they get a percentage of the GIVbacks for the first month or even quarter.
Not sure that if we do this, the max 50%, min 10%, $10 plateau would still make sense per transaction or in the round’s total. Maybe in this case we could leave a fix percentage as it would stick for a longer time.
Pay out the initial amount for development to Chainvine (1.5 Eth), the rest will be paid once the program is live.
We need to have a development call with @mateodaza & @cquinterom096 and their dev team to make sure the API integration is working from our donation flow to their system.
Their solution allows us to have full control over the rewards distribution (we’ll export the addresses and need to include them in our GIVbacks calculation), so we’ll include it as part of the GIVbacks program and need to also have a final discussion around the rewards distribution calculation and how that affects our GIVbacks calculation
We’ll need to figure out the comms roll out, including what is our launch strategy, what will we call it (GIVferral, GIVilliates?), do we need a landing page, blog post, twitter space, how will it be mentioned on our platform etc.
Once it’s approved, I’ll create an epic to go through all of this!
I think we can just say we are adding referrals to our GIVback program as opposed to making it a whole new GIV thing… That said, I brainstormed some names
@aabugosh Thanks, the idea is brilliant. Just I am afraid I have gotten it correctly!
Do we want to generate user-based referral links to projects and make any donations made via those links become eligible for the referral program?
If yes, I don’t think we would need lots of effort on the development side if we do it ourselves! If I haven’t underestimated it, we can generate referral links by adding a single parameter (referral wallet address or ENS) to the end of the project URL. That would be compatible with instant preview too. @Cherik Am I right?
The next step would be passing the referral information along with the donation information. This part would not be different when we use Chainvine or not.
Hey @amin! That’s correct, so basically the main things that Chainvine is doing is:
Generating a referral link for each user that automatically would track any new user that makes a donation through their link. This would need to be cookie-based though, since we need it to track the entire session (not just that page, but also if they navigate to other projects and other pages, it still needs to store that data in the user’s session). If we do it on our own, we’d need to make sure that we’re constantly looking at the referral and referrer value for each project (as an event listener), which would need work to configure to make it persist somewhere as a value in our database. With Chainvine, they already do that for us. We direct users to their platform, they store their data of the referral process and then we pass them the donation success to their API so it’s done through them, they just need the success case when a donation goes through.
User’s should have a way to view their rewards (their own dashboard). For example, they can see that I helped refer X number of new donors and I got Y rewards from it, so we’d need to create that too.
There should also be a referral landing page (a place where people go for them to see what the program is about and for them to sign up either as a referrer or a referrer).
If we could solve those we could do it on our own, however for now I suggest we use Chainvine to pilot it and see what the exact flow is for our platform (for at least 6 months, since that’s what we initially agreed on), then we can re-evaluate if we want to do it in-house or continue working with them if it runs smoothly and we’re benefitting from it!
If I got it correctly, we have to build items 2 and 3 ourselves.
Regarding item 1, again keeping referral info in the session storage must be implemented on our part. The new view is a dashboard to show who has used the referral link to donate. Anyway, we must implement a dashboard for the user to track his givbacks reward through the referral program, that information can be part of it.
I considered the referrer info a simple wallet address or ens address. If you think that addresses our need, it seems there would not be many challenges.
I will bring up this in our development weekly call and post the updates here.
I totally agree with you @amin,
we can consider a unique address for each user for example: https://giveth.io/ref/cherik?go=donate
when the user goes to this address we show a page to the user that you are coming from the Cherik referral code, and after some seconds redirect it to the donate page.
we can save the referer address or id to the cookie and let the backend knows at each request.
and about the expiration, It’s totally about the business logic of this part. but we can only use this referral code for that session. I mean after the user refreshes the page or if it visits giveth after someday we can remove that code and send requests with no referral code.
@Griff suggested pitching in here with opinions, as this is a very particular situation. On the one hand, we have a funding proposal already passed by the DAO, but on the other, the dev team (those closer to the issue) are suggesting building this in-house. Here are my thoughts:
Once the flow has been broken into pieces, I think @amin brings up a great point, that still most of the development will fall into the Giveth’s core dev team. i.e. Add referral rewards to dashboards, any landing page for this purpose, keep referral info in the session storage and sounds to me like the referral unique address and cookie tracking wouldn’t be too much effort.
Considering that and the issues that came up in the past with deliveries from previous projects, I could change my vote.
I suggest making a call with @aabugosh@amin@Cherik@Griff and other team members interested, to discuss this further and after discussing possible pathways come back to the community and let the community decide.
I think especially since it passed already (and we already paid the first amount to Chainvine), we should go ahead with it as a v1 to beta test the program. This will allow us to see how the system works, test out if makes sense for us and better scope out the system if we do decide to do it on our own later on. At the moment I’m not super confident that we collectively know what the product specs or exact user stories are for this yet to do it fully in-house.
I wanted to clarify about the point @Cotabe and @amin mentioned about the work needed from our dev team. As far as I know, all we need to do is connect to their API for each successful donation event (they’ll do all the rest, including tracking the sessions, having a rewards dashboard, landing page etc. on their own domain), see their docs here, so I don’t think there will be a ton of work to get it integrated.
I’ll be happy to have a call with everyone, but I suggest that @mateodaza@cquinterom096 also join (since they’ve been the main people coordinating on this project so far).
Thanks for the clarifications @aabugosh this is very helpful. I think your suggestion makes sense.
I would still suggest to discuss the details at a call. It could be a specific purpose one or maybe at next weekly dev call or GIVeconomy call where @amin@Cherik@mateodaza@cquinterom096@Griff usually assist.
I made a poll to signal sentiment.
No need to discuss this in a call
Let’s make a single purpose call for this
Let’s discuss this at Dapp backlog call
Let’s discuss this at the GIVeconomy development call
Thanks @Cotabe! For sure, I think a call is very much needed to have a discussion and make sure we’re all on the same page. I just voted but willing to attend any time the majority votes on
