I favor a URL solution cause I think is easier to parse and maintain.I also think the supported set of reftags should be very short, for example: https://aws.amazon.com/marketplace/help/201349870Note that Varnish supports url rewriting: https://www.varnish-cache.org/trac/wiki/RedirectsAndRewritesand I believe we are already taking advantage of rewriting at that layer:On Mon, Feb 23, 2015 at 5:25 PM, Toby Negrin <tnegrin@wikimedia.org> wrote:Make it shorter -- mostly machines will be reading it.On Mon, Feb 23, 2015 at 5:15 PM, Max Semenik <msemenik@wikimedia.org> wrote:As already said during that meaning, "source" conflicts with a bunch of things. "provenance" is unintelligible to a lot of people. Do you have any evidence that "analytics" clashes with anything?On Mon, Feb 23, 2015 at 5:11 PM, Kevin Leduc <kevin@wikimedia.org> wrote:Personally, I would rather see the parameter named something other than "analytics". It's too generic. I would suggest using "source", "provenance" or even "share_a_fact"On Mon, Feb 23, 2015 at 5:10 PM, Kevin Leduc <kevin@wikimedia.org> wrote:Oliver, the discussion is on the formatting of the URL that is posted on user's twitter or facebook feed when they use the "share a fact" feature. We can't set headers at this point because users are clicking on the like from another site.On Mon, Feb 23, 2015 at 4:50 PM, Oliver Keyes <okeyes@wikimedia.org> wrote:Why not just throw something into x_analytics and aggregate by that value?
> _______________________________________________
On 23 February 2015 at 19:41, Adam Baso <abaso@wikimedia.org> wrote:
> Hi all -
>
> I'm checking with people in ops, but we're planning to add a well defined
> parameter to the end of URLs to see the level of clickthroughs on such
> links. For example:
>
> https://en.wikipedia.org/wiki/Epirus?analytics=ios_share_a_fact_v1
>
> (If there are existing params on the URL - not an issue so far that I know
> of for the apps as they canonicalize the title and URL - then the param
> would be last in the ampersand separated query string parameter.)
>
> And then we'd use Varnish to remove the parameter to reduce the risk of
> cache fragmentation.
>
> We "know" this is probably only a short term solution, and as a follow up
> from the meeting with the people on the CC line, I'm emailing to open the
> discussion on options for a more generic option.
>
> So far I think there are a few options from what we've discussed, if we're
> to support additional bucketing.
>
> (1) More parameters (e.g., ?analytics=ios_share_a_fact&version=1)
> Downside: potentially harder to standardize and remove things from the URL
>
> (2) More conventional provenance (e.g.,
> https://en.wikipedia.org/w/index.php?title=Castle&oldid=645632619/ref=_wref_source%3Dapp<...more
> provenance info as desired>/).
> Downside: technically speaking, may break the schema of well-formed titles
>
> (3) Rely upon (1) or (2), or perhaps an even more RESTful shortlinker (it
> could have features like target - web or w:// wor wiki:// protocol or
> whatever - versioning, etc.).
> Downside: maybe a little more work to stand up service. As we recalled,
> there's an extension out there that may, perhaps with some tweaks, fit the
> build.
>
>
>
>
> -Adam
>
>
> Analytics mailing list
> Analytics@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/analytics
>
--
Oliver Keyes
Research Analyst
Wikimedia Foundation
_______________________________________________
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
_______________________________________________
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
_______________________________________________
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
_______________________________________________
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics