Makes sense. More context needed in initial emails! Or something ;p. "?saf=[value]"?
On 23 February 2015 at 20:25, 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