I favor a URL solution cause I think is easier to parse and maintain. "https://en.wikipedia.org/wiki/ref=app/Barack_Obama"
I also think the supported set of reftags should be very short, for example: https://aws.amazon.com/marketplace/help/201349870
Note that Varnish supports url rewriting: https://www.varnish-cache.org/trac/wiki/RedirectsAndRewrites and I believe we are already taking advantage of rewriting at that layer: https://github.com/wikimedia/operations-puppet-varnish/blob/master/templates...
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=_w... <...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