capture source via querystring arg



6 years ago
2 years ago


(Reporter: glind, Assigned: willkg)



(Whiteboard: u=dev c=general p=2 s=input.2014q1)

From Aurora feedback toolbar button, I want to send:

* Fire prevention:  Is this going to create any issue?   
* Potential Awesome:  Will this get recorded anywhere

My Ask:

* "yes, this is fine, even though we can't do anything with it"
* "no, don't do this."
* "yes, but... " (modification x)
Severity: blocker → normal
In the current input, querystring parameter the site cares about is url=, this will be completely ignored.

Fjord (input v2) will also be fine.

Can I ask why you want to send it? We may (eventually) be able to help more than just completely ignoring a querystring param if we know what you want to do.
Flags: needinfo?(glind)
Queryargs here would be a convenient solution for understanding what source led to `feedback`.  Toolbar button?  Help menu?
Flags: needinfo?(glind)
Putting these in my queue for this quarter.
Assignee: nobody → willkg
Whiteboard: u=dev c=general p= s=input.2013q2
Whiteboard: u=dev c=general p= s=input.2013q2 → u=dev c=general p= s=input.2013q3
I'm still not entirely sure what to do with this.

Matt: Does this information help you with metrics? If so, we should figure out what to do for 2013q4.

Putting this in 2013q4 for now just so it gets triaged.
Flags: needinfo?(mgrimes)
Whiteboard: u=dev c=general p= s=input.2013q3 → u=dev c=general p= s=input.2013q4
Duplicate of this bug: 843710
From bug #843710:

> Input should know the source. Possible places (non-exclusive):
> * help menu
> * Aurora button
> * survey / direct link.
> As part of re-review of 841437, we want to have 'metrics for success', which here is 2x total usage from Aurora button.
Thanks for flagging this. I do see value in understanding where our traffic is coming from, but I'm not convinced it takes priority over some of the other projects we have slated for q4. Let's discuss next week as I'm sure I'll have some additional questions.
Flags: needinfo?(mgrimes)
Bumping this to next quarter because I'm still fuzzy on exactly what this entails data-model-wise and I've got a bunch of stuff I need to do this quarter anyhow.
Whiteboard: u=dev c=general p= s=input.2013q4 → u=dev c=general p= s=input.2014q1
Changing the summary which sort of changes the scope of this bug.

New scope:

This bug covers handling a src querystring argument and storing a truncated form of that value in the database alongside the response. The src querystring argument will let us separate the organic feedback (people leaving feedback of their own accord) from campaign-like feedback (people leaving feedback after clicking on a link in a newsletter, from a blog post, or some other solicitation).

This only covers changes for the non-Input-API forms. We can figure out what to do with the Input API in another bug.
Summary: input urls are robust to query args → capture source via querystring arg
Changing my mind. I'm adding handling for capturing GA-like utm_source and utm_campaign querystring params and storing them in source and campaign fields in the db.

Landed in master in:

Pushed to production just now.
Last Resolved: 5 years ago
Resolution: --- → FIXED
This took about a day all told. Marking it as 2 points.
Whiteboard: u=dev c=general p= s=input.2014q1 → u=dev c=general p=2 s=input.2014q1
Product: Input → Input Graveyard
You need to log in before you can comment on or make changes to this bug.