Allow participants to get credit for recruiting new participants - SCOPING
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 12
- Forks
- 21
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 5
Description
# TL;DR
Set up to collect a "referral code" field for new participants and view codes of new participants, so that we can tell that family A referred family B to Lookit.
# Narrative
Participant word-of-mouth referrals are valuable and could be substantially more efficient than paid advertising if we could compensate families directly for referring others.
# TODO during scoping
- Confirm with MIT whether we can compensate families for referrals
- Confirm with MIT what options we have on compensation (non-Amazon) if so
# Acceptance Criteria - TODO, DRAFT
- [ ] Each participant account is associated with a unique referral code. (Researcher accounts are not associated with referral links.)
- [ ] Participants can see a referral link or code in their account view, with instructions about how it works
- [ ] Someone who follows a referral link or enters a referral code upon registration has that code and/or a reference to the referring account saved with their account. If you already have an account and use the referral link to get to Lookit, nothing about your account changes.
- [ ] There is an event hook on consent approval that - if referral credit has not already been assigned and a referrer exists, notifies Lookit admins of referrer/referred IDs, creates any necessary objects, and flags that the referral credit has been assigned.
- [ ] If consent is approved, rejected, and approved again for the first study a referred family does, that counts as one referral, not two. If consent is approved, then rejected, that counts as one referral. I.e., the first time consent is approved is permanent.
- [ ] A staff member with a specific permission can see a list of participants including ID, referral code, participant code the referral belongs to if appropriate, and an editable "processed" field for each of the two participants (e.g. to cover whether they have been compensated for the referral). Ideally this would include (for now) a space to enter a gift card code and a button to send an email with the code to the recipient, for each user.
- [ ] Shortcut buttons allow emailing participants from the above view
- [ ] In the "your account" section, the referring family can see how many other families they have referred who have successfully completed at least one study (defined as consent being approved).
- [ ] The count above is added to the "manage recruitment" view, i.e. we can see a distribution of how many people each family refers.
**Implementation Notes**
We could use [pinax-referrals](https://github.com/pinax/pinax-referrals) although it may be overkill.
* Probably model referral codes with a separate ReferralToken model that maps user IDs -> unique codes
* Add to urls so we can access the referral code during registration
* Add referrerID, referralCreditAssigned to user model
* May also want to model successfulReferral object (with referrerID, refereeID, timestamp) for display to admin and use in counting up referrals
* We could try to set up something more flexible to track different sorts of actions (rather than a single "you have been successfully referred upon first consent approval") but my impression is it will be substantially more work up front without any clear imagined use case.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by resolving the open scoping questions with MIT, then trace participant registration, account views, consent approval, and manage recruitment using the implementation notes. Evaluate the proposed ReferralToken and successful referral models, referral URLs, permissioned staff view, and any pinax-referrals integration; done requires finalized acceptance criteria before implementation begins.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100