Record reportback source from web submissions

[mshmsh5000]

FEATURE OVERVIEW

User Story

As an admin, I'd like to track reportback activity via the source param when appended to a campaign URL. For instance, if I send traffic to ds/us/campaigns/good_-times?source=campaign-digest, and a member submits a reportback from that URL, the reportback_file.source value should be campaign-digest.

Additional Information (optional)

We have a source column on reportback_file, where we currently track origin for SMS- and mobile-app-originated reportbacks.

Why This Matters

We should be able to append the source param to campaign URLs to see more easily which sources (e.g., the campaign digest) are driving reportbacks.

Current Workaround w/o Feature (if applicable)

N/A

[angaither]

@mshmsh5000 can you add more info on what we should be storing here? for which submissions? which urls?

[mshmsh5000]

@angaither Added clarity (I hope) and an example to the user story. Is there anything else I can add here? Other considerations?

[angaither]

@mshmsh5000 hmm

I think we should think about this some more. Because I'm wondering how this would work with other sources.

i.e if a user signs up from another user's social share link, the source would be user/[northstar_id] and the reportback source would then be User Y reported back via User X

or source=facebook User X reported back via facebook.

that doesn't reallllly mean source in the way we are currently thinking about a reportback source
the way it's currently used is the user is reporting back FROM a device/method, not how they found out about the campaign

[mshmsh5000]

Hmm, I see your point. But then there's further confusion, because we seem to be considering this source and field_user_registration_source_value in different ways—unless I'm also misunderstanding that. Because I thought we just opened up the registration source to all possible uses.

Three possible ways forward:

1. Do nothing
2. Open up this source column for more general usage
3. Add another column to distinguish device/method from the "referral" sense of source

Option 1

• Pro: No work
• Con: We have less explicit information about sources that drive reportback activity, our primary KPI

Option 2

• Pro: We can track all kinds of referral sources that might drive RB activity
• Cons: Possible confusion among methods/devices vs. referral sources; light engineering work

I can't think of a practical instance where that first Con bites us too hard.

Option 3:

• Pros: We can track all kinds of referral sources; we have clarity between devices/methods and referral sources
• Con: Schema change; light engineering work

[angaither]

I thought we just opened up the registration source to all possible uses.

we opened signup source, as in a campaign signup source, not a user registration source. the field_user_registration_source_value only gets set if a user is created via the API.