enhance: referral notifications with source #1862
Conversation
Soxasora
changed the title
Soxasora
force-pushed
the
referral_link_on_notification
branch
from
d1fc5a7 to
9617ad7
Compare
Soxasora
force-pushed
the
referral_link_on_notification
branch
from
9617ad7 to
7e33dea
Compare
Soxasora
changed the title
| profile { | ||
| name | ||
| } | ||
| } |
There was a problem hiding this comment.
This is a nitpick. But because these are mutually exclusive, it'd be more idiomatic to use a graphql union.
There was a problem hiding this comment.
When someone joins (and is a referree), we use cookies to assign their referrer. One day referrers only apply to referring other logged in stackers (stackers that have already joined).
The relevant code is:
- where one day referrers are recorded:
Line 59 in 95e9850
- this is where
r/<referrer>is handled and passed along:Line 15 in 95e9850
- when someone signs up, we grab the referral from cookies and attribute the referrer here:
I'm not sure what exactly needs to change to know which referral someone joined through, but using one day referrers won't do it.
Oh, now I understand correctly the behavior, what seemed to confuse me was the fact that after signup the user would be redirected to the page they were before, giving me a correct referral source. But this wouldn't work if they sign up from a different page or get redirected somewhere else. Mmh, I think that recording the first referred page they visit can suffice here but we would lose elasticity as in if they ever decide to sign up because of another referred content or user, it would still pick the first referral link they visited. I'll come up with an alternative. |
|
Perhaps the move on sign up is to insert a row into the one day referrer table, and mark it with a boolean. |
pages/api/auth/[...nextauth].js
Outdated
| if (req.cookies.sn_referrer && user?.id) { | ||
| const referrerId = await getReferrerId(req.cookies.sn_referrer) | ||
| if (referrerId && referrerId !== parseInt(user?.id)) { | ||
| if (req.cookies.sn_referee_landing) { // if we have a landing referrer, record it | ||
| const refereeLanding = await getRefereeLanding(req.cookies.sn_referee_landing, user.id) | ||
| if (refereeLanding) await prisma.oneDayReferral.create({ data: refereeLanding }) | ||
| } | ||
| const { count } = await prisma.user.updateMany({ where: { id: user.id, referrerId: null }, data: { referrerId } }) | ||
| if (count > 0) notifyReferral(referrerId) | ||
| } |
There was a problem hiding this comment.
Here I kept the same logic and re-used some stuff that was already there
| async function getRefereeLanding (refereeLanding, refereeId) { | ||
| const referrerId = await getReferrerId(refereeLanding) | ||
| if (!referrerId) return null // we only record if it's a valid content | ||
|
|
||
| let type, typeId | ||
|
|
||
| if (refereeLanding.startsWith('item-')) { | ||
| typeId = refereeLanding.slice(5) | ||
| const item = await prisma.item.findUnique({ where: { id: parseInt(typeId) } }) | ||
| type = item?.parentId ? 'COMMENT' : 'POST' | ||
| } else if (refereeLanding.startsWith('profile-')) { | ||
| type = 'PROFILE' | ||
| typeId = refereeLanding.slice(8) | ||
| } else if (refereeLanding.startsWith('territory-')) { | ||
| type = 'TERRITORY' | ||
| typeId = refereeLanding.slice(10) | ||
| } | ||
|
|
||
| return { referrerId, refereeId, type, typeId, landing: true } | ||
| } | ||
|
|
There was a problem hiding this comment.
It will exit the moment it doesn't find an ID following the contentReferrer criteria, causing the referee to not have a 'refereeLanding'. The referrer will have this generic notification
Description
Addresses #1861
Includes the source of referral on referral notification, showing the related Item, profile or territory.
Instead of getting data from the first entry of OneDayReferral, we push a row containing the referee's landing page, marked with a boolean.
Screenshots
General and Post
Comment
Profile
Territory
Additional Context
If there's nothing to show or the referral has type REFERRAL, it shows "because of you", as usual.
Push notification that shows "because of you" can probably stay the same, notifications page would provide more details
Checklist
Are your changes backwards compatible? Please answer below:
Yes
On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:
7, tested with multiple referral types
For frontend changes: Tested on mobile, light and dark mode? Please answer below:
Yes
Did you introduce any new environment variables? If so, call them out explicitly here:
No