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
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
The header?
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
(as opposed to the URL)
On Mon, Feb 23, 2015 at 5:09 PM, Adam Baso abaso@wikimedia.org wrote:
The header?
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
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
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
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
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
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
On 23 February 2015 at 17:37, Oliver Keyes okeyes@wikimedia.org wrote:
"?saf=[value]"?
Nice.
Pending the longer-term solution, we'll probably go with this.
Dan
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
Please pleas please. We have already iterated countlessly about it. _Do_ _not_ break the well-established URL schema. There is no good reason for it, really.
On Mon, Feb 23, 2015 at 5:39 PM, Nuria Ruiz nuria@wikimedia.org wrote:
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
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Adam Baso, 24/02/2015 01:41:
(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
Break, how so? Parameters to short URLs are a hack which is not in MediaWiki core. (2) is more standard, not less, AFAICS. Any MediaWiki code should follow the {{fullurl:}} pattern. Of course this is not MediaWiki code and we already have things like wiki/Special:Search?search=query&sourceid=Mozilla-search
Nemo
Hi Nemo - I think the concern was that it might be the case that the 'title' parameter may be at the end of the URL, and the 'title' parameter could in principle support a value with forward slashes potentially indistinguishable from the string in option #2. Of course, regular expressions can make anything possible in theory :) Anybody else able to explain further on the title schema risk?
-Adam
On Mon, Feb 23, 2015 at 10:42 PM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Adam Baso, 24/02/2015 01:41:
(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
Break, how so? Parameters to short URLs are a hack which is not in MediaWiki core. (2) is more standard, not less, AFAICS. Any MediaWiki code should follow the {{fullurl:}} pattern. Of course this is not MediaWiki code and we already have things like wiki/Special:Search?search= query&sourceid=Mozilla-search
Nemo
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
On Tue, Feb 24, 2015 at 9:48 AM, Adam Baso abaso@wikimedia.org wrote:
Hi Nemo - I think the concern was that it might be the case that the 'title' parameter may be at the end of the URL, and the 'title' parameter could in principle support a value with forward slashes potentially indistinguishable from the string in option #2. Of course, regular expressions can make anything possible in theory :) Anybody else able to explain further on the title schema risk?
Well, it doesn't work. Not sure I'd call that a risk though :-) How did that even come up? Why not use an ampersand instead of a forward slash? Ampersands have a well-defined meaning in the query part of the URL, while slashes don't.
Personally, I would favor the URL shortener. It is a useful feature on it's own, good for branding (if you don't shorten, many sites will shorten for you using their own schema, which results in nondescript URLs), you get nice URLs (in the short URL you can just factor the parameters into the shortened part, in the full URL you don't need them because the user has been counted already), you get less cache fragmentation (even if you remove the parameter in Varnish, you'll still fragment the client cache). On the negative side, it's one more request so clicking through becomes somewhat slower.
it sounds like we have consensus for a short-term solution based on a vanilla parameter, as long as it doesn’t clash with other internal parameters. I agree with Gergo that a shortener is appealing as a long-term solution, this is what the vast majority of platforms are using for analytics purposes, it also has the added benefit of addressing the impact of referrer information being stripped for HTTPS requests. If there’s no other objection, we can safely fold this under the discussion of long-term options and go ahead with the proposed implementation, per Dan.
Thanks, everybody.
On Feb 24, 2015, at 11:56 AM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Feb 24, 2015 at 9:48 AM, Adam Baso <abaso@wikimedia.org mailto:abaso@wikimedia.org> wrote: Hi Nemo - I think the concern was that it might be the case that the 'title' parameter may be at the end of the URL, and the 'title' parameter could in principle support a value with forward slashes potentially indistinguishable from the string in option #2. Of course, regular expressions can make anything possible in theory :) Anybody else able to explain further on the title schema risk?
Well, it doesn't work. Not sure I'd call that a risk though :-) How did that even come up? Why not use an ampersand instead of a forward slash? Ampersands have a well-defined meaning in the query part of the URL, while slashes don't.
Personally, I would favor the URL shortener. It is a useful feature on it's own, good for branding (if you don't shorten, many sites will shorten for you using their own schema, which results in nondescript URLs), you get nice URLs (in the short URL you can just factor the parameters into the shortened part, in the full URL you don't need them because the user has been counted already), you get less cache fragmentation (even if you remove the parameter in Varnish, you'll still fragment the client cache). On the negative side, it's one more request so clicking through becomes somewhat slower. _______________________________________________ Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
If there’s no other objection, we can safely fold this under the
discussion of long-term options and go ahead with the proposed
implementation, per Dan.
I think there are some technical issues to be ironed right?
1. How are we doing so a request like: *http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value* is counted as a pageview towards the BarakObama page? Is that already taken care of?
2. What about caching? Is this page:* http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value* being served from the cache as it should be?
Until 1 and 2 have answers (specially 2) we should not proceed to implementations on the client.
Adam: Did you looked into caching issues?
Thanks,
Nuria
On Tue, Feb 24, 2015 at 3:00 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
it sounds like we have consensus for a short-term solution based on a vanilla parameter, as long as it doesn’t clash with other internal parameters. I agree with Gergo that a shortener is appealing as a long-term solution, this is what the vast majority of platforms are using for analytics purposes, it also has the added benefit of addressing the impact of referrer information being stripped for HTTPS requests. If there’s no other objection, we can safely fold this under the discussion of long-term options and go ahead with the proposed implementation, per Dan.
Thanks, everybody.
On Feb 24, 2015, at 11:56 AM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Feb 24, 2015 at 9:48 AM, Adam Baso abaso@wikimedia.org wrote:
Hi Nemo - I think the concern was that it might be the case that the 'title' parameter may be at the end of the URL, and the 'title' parameter could in principle support a value with forward slashes potentially indistinguishable from the string in option #2. Of course, regular expressions can make anything possible in theory :) Anybody else able to explain further on the title schema risk?
Well, it doesn't work. Not sure I'd call that a risk though :-) How did that even come up? Why not use an ampersand instead of a forward slash? Ampersands have a well-defined meaning in the query part of the URL, while slashes don't.
Personally, I would favor the URL shortener. It is a useful feature on it's own, good for branding (if you don't shorten, many sites will shorten for you using their own schema, which results in nondescript URLs), you get nice URLs (in the short URL you can just factor the parameters into the shortened part, in the full URL you don't need them because the user has been counted already), you get less cache fragmentation (even if you remove the parameter in Varnish, you'll still fragment the client cache). On the negative side, it's one more request so clicking through becomes somewhat slower. _______________________________________________ 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
On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org wrote:
- What about caching?
Is this page:* http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value* being served from the cache as it should be?
The file download parameter was handled via this patch: https://gerrit.wikimedia.org/r/#/c/120617/ Seems like an analogous scenario.
Ping ... (regarding cache question)
On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org wrote:
- What about caching?
Is this page:* http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value* being served from the cache as it should be?
The file download parameter was handled via this patch: https://gerrit.wikimedia.org/r/#/c/120617/ Seems like an analogous scenario.
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 about modeling after that patch. That sort of approach should avoid cache fragmentation.
As for parameter name, 'wmfxan' is short and I think would avoid collisions. Any problems with this parameter name?
-Adam
On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org wrote:
Ping ... (regarding cache question)
On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org wrote:
- What about caching?
Is this page:* http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value* being served from the cache as it should be?
The file download parameter was handled via this patch: https://gerrit.wikimedia.org/r/#/c/120617/ Seems like an analogous scenario.
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
Oof, only that it is ugly! :)
Can you just call it ‘provenance', or are you trying to be more future proof?
On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote:
I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 https://phabricator.wikimedia.org/T90606 about modeling after that patch. That sort of approach should avoid cache fragmentation.
As for parameter name, 'wmfxan' is short and I think would avoid collisions. Any problems with this parameter name?
-Adam
On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz <nuria@wikimedia.org mailto:nuria@wikimedia.org> wrote: Ping ... (regarding cache question)
On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza <gtisza@wikimedia.org mailto:gtisza@wikimedia.org> wrote: On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz <nuria@wikimedia.org mailto:nuria@wikimedia.org> wrote: 2. What about caching? Is this page: http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value being served from the cache as it should be?
The file download parameter was handled via this patch: https://gerrit.wikimedia.org/r/#/c/120617/ https://gerrit.wikimedia.org/r/#/c/120617/ Seems like an analogous scenario.
Analytics mailing list Analytics@lists.wikimedia.org mailto:Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics https://lists.wikimedia.org/mailman/listinfo/analytics
Analytics mailing list Analytics@lists.wikimedia.org mailto:Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics https://lists.wikimedia.org/mailman/listinfo/analytics
Ha! I'm cool with 'provenance' if no one objects.
On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org wrote:
Oof, only that it is ugly! :)
Can you just call it ‘provenance', or are you trying to be more future proof?
On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote:
I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 about modeling after that patch. That sort of approach should avoid cache fragmentation.
As for parameter name, 'wmfxan' is short and I think would avoid collisions. Any problems with this parameter name?
-Adam
On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org wrote:
Ping ... (regarding cache question)
On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org wrote:
- What about caching?
Is this page:* http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value* being served from the cache as it should be?
The file download parameter was handled via this patch: https://gerrit.wikimedia.org/r/#/c/120617/ Seems like an analogous scenario.
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
I'd really rather this be either something that's totally not understandable by the user (e.g. ?saf=1), or something that is clearly understandable (e.g. ?appshareafact=1).
Dan
On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote:
Ha! I'm cool with 'provenance' if no one objects.
On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org wrote:
Oof, only that it is ugly! :)
Can you just call it ‘provenance', or are you trying to be more future proof?
On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote:
I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 about modeling after that patch. That sort of approach should avoid cache fragmentation.
As for parameter name, 'wmfxan' is short and I think would avoid collisions. Any problems with this parameter name?
-Adam
On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org wrote:
Ping ... (regarding cache question)
On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org wrote:
- What about caching?
Is this page:* http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value* being served from the cache as it should be?
The file download parameter was handled via this patch: https://gerrit.wikimedia.org/r/#/c/120617/ Seems like an analogous scenario.
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
How about 'wprov'?
On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org wrote:
I'd really rather this be either something that's totally not understandable by the user (e.g. ?saf=1), or something that is clearly understandable (e.g. ?appshareafact=1).
Dan
On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote:
Ha! I'm cool with 'provenance' if no one objects.
On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org wrote:
Oof, only that it is ugly! :)
Can you just call it ‘provenance', or are you trying to be more future proof?
On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote:
I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 about modeling after that patch. That sort of approach should avoid cache fragmentation.
As for parameter name, 'wmfxan' is short and I think would avoid collisions. Any problems with this parameter name?
-Adam
On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org wrote:
Ping ... (regarding cache question)
On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org wrote:
- What about caching?
Is this page:* http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value* being served from the cache as it should be?
The file download parameter was handled via this patch: https://gerrit.wikimedia.org/r/#/c/120617/ Seems like an analogous scenario.
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
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Works for me.
Dan
On 4 March 2015 at 12:33, Adam Baso abaso@wikimedia.org wrote:
How about 'wprov'?
On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org wrote:
I'd really rather this be either something that's totally not understandable by the user (e.g. ?saf=1), or something that is clearly understandable (e.g. ?appshareafact=1).
Dan
On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote:
Ha! I'm cool with 'provenance' if no one objects.
On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org wrote:
Oof, only that it is ugly! :)
Can you just call it ‘provenance', or are you trying to be more future proof?
On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote:
I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 about modeling after that patch. That sort of approach should avoid cache fragmentation.
As for parameter name, 'wmfxan' is short and I think would avoid collisions. Any problems with this parameter name?
-Adam
On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org wrote:
Ping ... (regarding cache question)
On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org wrote:
> 2. What about caching? > Is this page:* > http://wikipedia.org/BarackObama?some_param=some-value > http://wikipedia.org/BarackObama?some_param=some-value* being > served from the cache as it should be? >
The file download parameter was handled via this patch: https://gerrit.wikimedia.org/r/#/c/120617/ Seems like an analogous scenario.
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
-- Dan Garry Associate Product Manager, Mobile Apps 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
Okay, we'll plan on wprov.
On Wed, Mar 4, 2015 at 12:44 PM, Dan Garry dgarry@wikimedia.org wrote:
Works for me.
Dan
On 4 March 2015 at 12:33, Adam Baso abaso@wikimedia.org wrote:
How about 'wprov'?
On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org wrote:
I'd really rather this be either something that's totally not understandable by the user (e.g. ?saf=1), or something that is clearly understandable (e.g. ?appshareafact=1).
Dan
On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote:
Ha! I'm cool with 'provenance' if no one objects.
On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org wrote:
Oof, only that it is ugly! :)
Can you just call it ‘provenance', or are you trying to be more future proof?
On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote:
I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 about modeling after that patch. That sort of approach should avoid cache fragmentation.
As for parameter name, 'wmfxan' is short and I think would avoid collisions. Any problems with this parameter name?
-Adam
On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org wrote:
Ping ... (regarding cache question)
On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza gtisza@wikimedia.org wrote:
> On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org > wrote: > >> 2. What about caching? >> Is this page:* >> http://wikipedia.org/BarackObama?some_param=some-value >> http://wikipedia.org/BarackObama?some_param=some-value* being >> served from the cache as it should be? >> > > The file download parameter was handled via this patch: > https://gerrit.wikimedia.org/r/#/c/120617/ > Seems like an analogous scenario. > > _______________________________________________ > 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
-- Dan Garry Associate Product Manager, Mobile Apps 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
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
For the first version on iOS, this will be
?wprov=safi1
And Android:
?wprov=safa1
-Adam
On Mon, Mar 9, 2015 at 1:39 PM, Adam Baso abaso@wikimedia.org wrote:
Okay, we'll plan on wprov.
On Wed, Mar 4, 2015 at 12:44 PM, Dan Garry dgarry@wikimedia.org wrote:
Works for me.
Dan
On 4 March 2015 at 12:33, Adam Baso abaso@wikimedia.org wrote:
How about 'wprov'?
On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org wrote:
I'd really rather this be either something that's totally not understandable by the user (e.g. ?saf=1), or something that is clearly understandable (e.g. ?appshareafact=1).
Dan
On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote:
Ha! I'm cool with 'provenance' if no one objects.
On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org wrote:
Oof, only that it is ugly! :)
Can you just call it ‘provenance', or are you trying to be more future proof?
On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote:
I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 about modeling after that patch. That sort of approach should avoid cache fragmentation.
As for parameter name, 'wmfxan' is short and I think would avoid collisions. Any problems with this parameter name?
-Adam
On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org wrote:
> Ping ... (regarding cache question) > > On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza gtisza@wikimedia.org > wrote: > >> On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org >> wrote: >> >>> 2. What about caching? >>> Is this page:* >>> http://wikipedia.org/BarackObama?some_param=some-value >>> http://wikipedia.org/BarackObama?some_param=some-value* being >>> served from the cache as it should be? >>> >> >> The file download parameter was handled via this patch: >> https://gerrit.wikimedia.org/r/#/c/120617/ >> Seems like an analogous scenario. >> >> _______________________________________________ >> 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
-- Dan Garry Associate Product Manager, Mobile Apps 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
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
On Tue, Mar 10, 2015 at 11:26 AM, Adam Baso abaso@wikimedia.org wrote:
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
Don't forget to document this publicly once it is deployed. https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php is probably a good place for that (even though technically these are not related to index.php, but that page is where I would look if I saw a new parameter and had no idea what's going on).
Is wprov only used by the apps? On Mar 10, 2015 12:59 PM, "Gergo Tisza" gtisza@wikimedia.org wrote:
On Tue, Mar 10, 2015 at 11:26 AM, Adam Baso abaso@wikimedia.org wrote:
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
Don't forget to document this publicly once it is deployed. https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php is probably a good place for that (even though technically these are not related to index.php, but that page is where I would look if I saw a new parameter and had no idea what's going on).
On Mar 10, 2015, at 11:26 AM, Adam Baso abaso@wikimedia.org wrote:
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
For the first version on iOS, this will be
?wprov=safi1
And Android:
?wprov=safa1
Thanks for the closing the loop on this. Dan, Adam – have you guys considered tagging the type of “share”? I expect “image shares” will have higher engagement/click-through than “text shares”, if that’s a data point you want to collect explicitly, you’ll want to pass a different value to 3_char_feature (assuming that’s possible).
Is the new parameter going to be in the next beta build?
Dario
On Mon, Mar 9, 2015 at 1:39 PM, Adam Baso <abaso@wikimedia.org mailto:abaso@wikimedia.org> wrote: Okay, we'll plan on wprov.
On Wed, Mar 4, 2015 at 12:44 PM, Dan Garry <dgarry@wikimedia.org mailto:dgarry@wikimedia.org> wrote: Works for me.
Dan
On 4 March 2015 at 12:33, Adam Baso <abaso@wikimedia.org mailto:abaso@wikimedia.org> wrote: How about 'wprov'?
On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry <dgarry@wikimedia.org mailto:dgarry@wikimedia.org> wrote: I'd really rather this be either something that's totally not understandable by the user (e.g. ?saf=1), or something that is clearly understandable (e.g. ?appshareafact=1).
Dan
On 4 March 2015 at 12:26, Adam Baso <abaso@wikimedia.org mailto:abaso@wikimedia.org> wrote: Ha! I'm cool with 'provenance' if no one objects.
On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto <aotto@wikimedia.org mailto:aotto@wikimedia.org> wrote: Oof, only that it is ugly! :)
Can you just call it ‘provenance', or are you trying to be more future proof?
On Mar 4, 2015, at 12:11, Adam Baso <abaso@wikimedia.org mailto:abaso@wikimedia.org> wrote:
I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 https://phabricator.wikimedia.org/T90606 about modeling after that patch. That sort of approach should avoid cache fragmentation.
As for parameter name, 'wmfxan' is short and I think would avoid collisions. Any problems with this parameter name?
-Adam
On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz <nuria@wikimedia.org mailto:nuria@wikimedia.org> wrote: Ping ... (regarding cache question)
On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza <gtisza@wikimedia.org mailto:gtisza@wikimedia.org> wrote: On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz <nuria@wikimedia.org mailto:nuria@wikimedia.org> wrote: 2. What about caching? Is this page: http://wikipedia.org/BarackObama?some_param=some-value http://wikipedia.org/BarackObama?some_param=some-value being served from the cache as it should be?
The file download parameter was handled via this patch: https://gerrit.wikimedia.org/r/#/c/120617/ https://gerrit.wikimedia.org/r/#/c/120617/ Seems like an analogous scenario.
Analytics mailing list Analytics@lists.wikimedia.org mailto:Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics https://lists.wikimedia.org/mailman/listinfo/analytics
Analytics mailing list Analytics@lists.wikimedia.org mailto:Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics https://lists.wikimedia.org/mailman/listinfo/analytics
Analytics mailing list Analytics@lists.wikimedia.org mailto:Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics https://lists.wikimedia.org/mailman/listinfo/analytics
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org mailto:Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics https://lists.wikimedia.org/mailman/listinfo/analytics
Analytics mailing list Analytics@lists.wikimedia.org mailto:Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics https://lists.wikimedia.org/mailman/listinfo/analytics
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org mailto:Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics https://lists.wikimedia.org/mailman/listinfo/analytics
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
wprov didn't seem to show up as a parameter in looking at the query field on an hour of logs on en.m.wikipedia.org via Hadoop, so I think we're okay there.
As for that additional data point, that's a good idea. Bernd, Dmitry, how about we do: sfi (image) and sft (text) ?
-Adam
On Tue, Mar 10, 2015 at 4:47 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
On Mar 10, 2015, at 11:26 AM, Adam Baso abaso@wikimedia.org wrote:
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
For the first version on iOS, this will be
?wprov=safi1
And Android: ?wprov=safa1
Thanks for the closing the loop on this. Dan, Adam – have you guys considered tagging the type of “share”? I expect “image shares” will have higher engagement/click-through than “text shares”, if that’s a data point you want to collect explicitly, you’ll want to pass a different value to 3_char_feature (assuming that’s possible).
Is the new parameter going to be in the next beta build?
Dario
On Mon, Mar 9, 2015 at 1:39 PM, Adam Baso abaso@wikimedia.org wrote:
Okay, we'll plan on wprov.
On Wed, Mar 4, 2015 at 12:44 PM, Dan Garry dgarry@wikimedia.org wrote:
Works for me.
Dan
On 4 March 2015 at 12:33, Adam Baso abaso@wikimedia.org wrote:
How about 'wprov'?
On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org wrote:
I'd really rather this be either something that's totally not understandable by the user (e.g. ?saf=1), or something that is clearly understandable (e.g. ?appshareafact=1).
Dan
On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote:
Ha! I'm cool with 'provenance' if no one objects.
On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org wrote:
> Oof, only that it is ugly! :) > > Can you just call it ‘provenance', or are you trying to be more > future proof? > > > > > > On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote: > > I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 > about modeling after that patch. That sort of approach should avoid cache > fragmentation. > > As for parameter name, 'wmfxan' is short and I think would avoid > collisions. Any problems with this parameter name? > > -Adam > > > On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org > wrote: > >> Ping ... (regarding cache question) >> >> On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza gtisza@wikimedia.org >> wrote: >> >>> On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org >>> wrote: >>> >>>> 2. What about caching? >>>> Is this page:* >>>> http://wikipedia.org/BarackObama?some_param=some-value >>>> http://wikipedia.org/BarackObama?some_param=some-value* being >>>> served from the cache as it should be? >>>> >>> >>> The file download parameter was handled via this patch: >>> https://gerrit.wikimedia.org/r/#/c/120617/ >>> Seems like an analogous scenario. >>> >>> _______________________________________________ >>> 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
-- Dan Garry Associate Product Manager, Mobile Apps 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
-- Dan Garry Associate Product Manager, Mobile Apps 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
Sounds good to me. On Mar 10, 2015 5:58 PM, "Adam Baso" abaso@wikimedia.org wrote:
wprov didn't seem to show up as a parameter in looking at the query field on an hour of logs on en.m.wikipedia.org via Hadoop, so I think we're okay there.
As for that additional data point, that's a good idea. Bernd, Dmitry, how about we do: sfi (image) and sft (text) ?
-Adam
On Tue, Mar 10, 2015 at 4:47 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
On Mar 10, 2015, at 11:26 AM, Adam Baso abaso@wikimedia.org wrote:
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
For the first version on iOS, this will be
?wprov=safi1
And Android: ?wprov=safa1
Thanks for the closing the loop on this. Dan, Adam – have you guys considered tagging the type of “share”? I expect “image shares” will have higher engagement/click-through than “text shares”, if that’s a data point you want to collect explicitly, you’ll want to pass a different value to 3_char_feature (assuming that’s possible).
Is the new parameter going to be in the next beta build?
Dario
On Mon, Mar 9, 2015 at 1:39 PM, Adam Baso abaso@wikimedia.org wrote:
Okay, we'll plan on wprov.
On Wed, Mar 4, 2015 at 12:44 PM, Dan Garry dgarry@wikimedia.org wrote:
Works for me.
Dan
On 4 March 2015 at 12:33, Adam Baso abaso@wikimedia.org wrote:
How about 'wprov'?
On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org wrote:
I'd really rather this be either something that's totally not understandable by the user (e.g. ?saf=1), or something that is clearly understandable (e.g. ?appshareafact=1).
Dan
On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote:
> Ha! I'm cool with 'provenance' if no one objects. > > On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org > wrote: > >> Oof, only that it is ugly! :) >> >> Can you just call it ‘provenance', or are you trying to be more >> future proof? >> >> >> >> >> >> On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote: >> >> I pinged on Phabricator at https://phabricator.wikimedia.org/T90606 >> about modeling after that patch. That sort of approach should avoid cache >> fragmentation. >> >> As for parameter name, 'wmfxan' is short and I think would avoid >> collisions. Any problems with this parameter name? >> >> -Adam >> >> >> On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org >> wrote: >> >>> Ping ... (regarding cache question) >>> >>> On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza <gtisza@wikimedia.org >>> > wrote: >>> >>>> On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz nuria@wikimedia.org >>>> wrote: >>>> >>>>> 2. What about caching? >>>>> Is this page:* >>>>> http://wikipedia.org/BarackObama?some_param=some-value >>>>> http://wikipedia.org/BarackObama?some_param=some-value* being >>>>> served from the cache as it should be? >>>>> >>>> >>>> The file download parameter was handled via this patch: >>>> https://gerrit.wikimedia.org/r/#/c/120617/ >>>> Seems like an analogous scenario. >>>> >>>> _______________________________________________ >>>> 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 > >
-- Dan Garry Associate Product Manager, Mobile Apps 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
-- Dan Garry Associate Product Manager, Mobile Apps 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
I've updated https://phabricator.wikimedia.org/T90606.
On Tue, Mar 10, 2015 at 6:48 PM, Bernd Sitzmann bernd@wikimedia.org wrote:
Sounds good to me. On Mar 10, 2015 5:58 PM, "Adam Baso" abaso@wikimedia.org wrote:
wprov didn't seem to show up as a parameter in looking at the query field on an hour of logs on en.m.wikipedia.org via Hadoop, so I think we're okay there.
As for that additional data point, that's a good idea. Bernd, Dmitry, how about we do: sfi (image) and sft (text) ?
-Adam
On Tue, Mar 10, 2015 at 4:47 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
On Mar 10, 2015, at 11:26 AM, Adam Baso abaso@wikimedia.org wrote:
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
For the first version on iOS, this will be
?wprov=safi1
And Android: ?wprov=safa1
Thanks for the closing the loop on this. Dan, Adam – have you guys considered tagging the type of “share”? I expect “image shares” will have higher engagement/click-through than “text shares”, if that’s a data point you want to collect explicitly, you’ll want to pass a different value to 3_char_feature (assuming that’s possible).
Is the new parameter going to be in the next beta build?
Dario
On Mon, Mar 9, 2015 at 1:39 PM, Adam Baso abaso@wikimedia.org wrote:
Okay, we'll plan on wprov.
On Wed, Mar 4, 2015 at 12:44 PM, Dan Garry dgarry@wikimedia.org wrote:
Works for me.
Dan
On 4 March 2015 at 12:33, Adam Baso abaso@wikimedia.org wrote:
How about 'wprov'?
On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org wrote:
> I'd really rather this be either something that's totally not > understandable by the user (e.g. ?saf=1), or something that is clearly > understandable (e.g. ?appshareafact=1). > > Dan > > On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote: > >> Ha! I'm cool with 'provenance' if no one objects. >> >> On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org >> wrote: >> >>> Oof, only that it is ugly! :) >>> >>> Can you just call it ‘provenance', or are you trying to be more >>> future proof? >>> >>> >>> >>> >>> >>> On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote: >>> >>> I pinged on Phabricator at >>> https://phabricator.wikimedia.org/T90606 about modeling after >>> that patch. That sort of approach should avoid cache fragmentation. >>> >>> As for parameter name, 'wmfxan' is short and I think would avoid >>> collisions. Any problems with this parameter name? >>> >>> -Adam >>> >>> >>> On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org >>> wrote: >>> >>>> Ping ... (regarding cache question) >>>> >>>> On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza < >>>> gtisza@wikimedia.org> wrote: >>>> >>>>> On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz <nuria@wikimedia.org >>>>> > wrote: >>>>> >>>>>> 2. What about caching? >>>>>> Is this page:* >>>>>> http://wikipedia.org/BarackObama?some_param=some-value >>>>>> http://wikipedia.org/BarackObama?some_param=some-value* >>>>>> being served from the cache as it should be? >>>>>> >>>>> >>>>> The file download parameter was handled via this patch: >>>>> https://gerrit.wikimedia.org/r/#/c/120617/ >>>>> Seems like an analogous scenario. >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> > > > -- > Dan Garry > Associate Product Manager, Mobile Apps > 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
-- Dan Garry Associate Product Manager, Mobile Apps 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
https://gerrit.wikimedia.org/r/#/c/198805/ submitted for review.
On Wed, Mar 11, 2015 at 9:31 AM, Adam Baso abaso@wikimedia.org wrote:
I've updated https://phabricator.wikimedia.org/T90606.
On Tue, Mar 10, 2015 at 6:48 PM, Bernd Sitzmann bernd@wikimedia.org wrote:
Sounds good to me. On Mar 10, 2015 5:58 PM, "Adam Baso" abaso@wikimedia.org wrote:
wprov didn't seem to show up as a parameter in looking at the query field on an hour of logs on en.m.wikipedia.org via Hadoop, so I think we're okay there.
As for that additional data point, that's a good idea. Bernd, Dmitry, how about we do: sfi (image) and sft (text) ?
-Adam
On Tue, Mar 10, 2015 at 4:47 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
On Mar 10, 2015, at 11:26 AM, Adam Baso abaso@wikimedia.org wrote:
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
For the first version on iOS, this will be
?wprov=safi1
And Android: ?wprov=safa1
Thanks for the closing the loop on this. Dan, Adam – have you guys considered tagging the type of “share”? I expect “image shares” will have higher engagement/click-through than “text shares”, if that’s a data point you want to collect explicitly, you’ll want to pass a different value to 3_char_feature (assuming that’s possible).
Is the new parameter going to be in the next beta build?
Dario
On Mon, Mar 9, 2015 at 1:39 PM, Adam Baso abaso@wikimedia.org wrote:
Okay, we'll plan on wprov.
On Wed, Mar 4, 2015 at 12:44 PM, Dan Garry dgarry@wikimedia.org wrote:
Works for me.
Dan
On 4 March 2015 at 12:33, Adam Baso abaso@wikimedia.org wrote:
> How about 'wprov'? > > On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org > wrote: > >> I'd really rather this be either something that's totally not >> understandable by the user (e.g. ?saf=1), or something that is clearly >> understandable (e.g. ?appshareafact=1). >> >> Dan >> >> On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote: >> >>> Ha! I'm cool with 'provenance' if no one objects. >>> >>> On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto aotto@wikimedia.org >>> wrote: >>> >>>> Oof, only that it is ugly! :) >>>> >>>> Can you just call it ‘provenance', or are you trying to be more >>>> future proof? >>>> >>>> >>>> >>>> >>>> >>>> On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote: >>>> >>>> I pinged on Phabricator at >>>> https://phabricator.wikimedia.org/T90606 about modeling after >>>> that patch. That sort of approach should avoid cache fragmentation. >>>> >>>> As for parameter name, 'wmfxan' is short and I think would avoid >>>> collisions. Any problems with this parameter name? >>>> >>>> -Adam >>>> >>>> >>>> On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz nuria@wikimedia.org >>>> wrote: >>>> >>>>> Ping ... (regarding cache question) >>>>> >>>>> On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza < >>>>> gtisza@wikimedia.org> wrote: >>>>> >>>>>> On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz < >>>>>> nuria@wikimedia.org> wrote: >>>>>> >>>>>>> 2. What about caching? >>>>>>> Is this page:* >>>>>>> http://wikipedia.org/BarackObama?some_param=some-value >>>>>>> http://wikipedia.org/BarackObama?some_param=some-value* >>>>>>> being served from the cache as it should be? >>>>>>> >>>>>> >>>>>> The file download parameter was handled via this patch: >>>>>> https://gerrit.wikimedia.org/r/#/c/120617/ >>>>>> Seems like an analogous scenario. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >> >> >> -- >> Dan Garry >> Associate Product Manager, Mobile Apps >> 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 > >
-- Dan Garry Associate Product Manager, Mobile Apps 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
And I created https://www.mediawiki.org/wiki/Provenance for reservation of the codes going forward.
On Mon, Mar 23, 2015 at 12:53 PM, Adam Baso abaso@wikimedia.org wrote:
https://gerrit.wikimedia.org/r/#/c/198805/ submitted for review.
On Wed, Mar 11, 2015 at 9:31 AM, Adam Baso abaso@wikimedia.org wrote:
I've updated https://phabricator.wikimedia.org/T90606.
On Tue, Mar 10, 2015 at 6:48 PM, Bernd Sitzmann bernd@wikimedia.org wrote:
Sounds good to me. On Mar 10, 2015 5:58 PM, "Adam Baso" abaso@wikimedia.org wrote:
wprov didn't seem to show up as a parameter in looking at the query field on an hour of logs on en.m.wikipedia.org via Hadoop, so I think we're okay there.
As for that additional data point, that's a good idea. Bernd, Dmitry, how about we do: sfi (image) and sft (text) ?
-Adam
On Tue, Mar 10, 2015 at 4:47 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
On Mar 10, 2015, at 11:26 AM, Adam Baso abaso@wikimedia.org wrote:
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
For the first version on iOS, this will be
?wprov=safi1
And Android: ?wprov=safa1
Thanks for the closing the loop on this. Dan, Adam – have you guys considered tagging the type of “share”? I expect “image shares” will have higher engagement/click-through than “text shares”, if that’s a data point you want to collect explicitly, you’ll want to pass a different value to 3_char_feature (assuming that’s possible).
Is the new parameter going to be in the next beta build?
Dario
On Mon, Mar 9, 2015 at 1:39 PM, Adam Baso abaso@wikimedia.org wrote:
Okay, we'll plan on wprov.
On Wed, Mar 4, 2015 at 12:44 PM, Dan Garry dgarry@wikimedia.org wrote:
> Works for me. > > Dan > > On 4 March 2015 at 12:33, Adam Baso abaso@wikimedia.org wrote: > >> How about 'wprov'? >> >> On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org >> wrote: >> >>> I'd really rather this be either something that's totally not >>> understandable by the user (e.g. ?saf=1), or something that is clearly >>> understandable (e.g. ?appshareafact=1). >>> >>> Dan >>> >>> On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote: >>> >>>> Ha! I'm cool with 'provenance' if no one objects. >>>> >>>> On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto <aotto@wikimedia.org >>>> > wrote: >>>> >>>>> Oof, only that it is ugly! :) >>>>> >>>>> Can you just call it ‘provenance', or are you trying to be more >>>>> future proof? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org wrote: >>>>> >>>>> I pinged on Phabricator at >>>>> https://phabricator.wikimedia.org/T90606 about modeling after >>>>> that patch. That sort of approach should avoid cache fragmentation. >>>>> >>>>> As for parameter name, 'wmfxan' is short and I think would avoid >>>>> collisions. Any problems with this parameter name? >>>>> >>>>> -Adam >>>>> >>>>> >>>>> On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz <nuria@wikimedia.org >>>>> > wrote: >>>>> >>>>>> Ping ... (regarding cache question) >>>>>> >>>>>> On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza < >>>>>> gtisza@wikimedia.org> wrote: >>>>>> >>>>>>> On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz < >>>>>>> nuria@wikimedia.org> wrote: >>>>>>> >>>>>>>> 2. What about caching? >>>>>>>> Is this page:* >>>>>>>> http://wikipedia.org/BarackObama?some_param=some-value >>>>>>>> http://wikipedia.org/BarackObama?some_param=some-value* >>>>>>>> being served from the cache as it should be? >>>>>>>> >>>>>>> >>>>>>> The file download parameter was handled via this patch: >>>>>>> https://gerrit.wikimedia.org/r/#/c/120617/ >>>>>>> Seems like an analogous scenario. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Dan Garry >>> Associate Product Manager, Mobile Apps >>> 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 >> >> > > > -- > Dan Garry > Associate Product Manager, Mobile Apps > 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
Brandon and Yuri helped improve the patch and get it tested on the beta cluster, and now it's in prod for the text and mobile Varnish frontends. Thanks everyone for helping out with this!
On Monday, March 23, 2015, Adam Baso abaso@wikimedia.org wrote:
And I created https://www.mediawiki.org/wiki/Provenance for reservation of the codes going forward.
On Mon, Mar 23, 2015 at 12:53 PM, Adam Baso abaso@wikimedia.org wrote:
https://gerrit.wikimedia.org/r/#/c/198805/ submitted for review.
On Wed, Mar 11, 2015 at 9:31 AM, Adam Baso abaso@wikimedia.org wrote:
I've updated https://phabricator.wikimedia.org/T90606.
On Tue, Mar 10, 2015 at 6:48 PM, Bernd Sitzmann bernd@wikimedia.org wrote:
Sounds good to me. On Mar 10, 2015 5:58 PM, "Adam Baso" abaso@wikimedia.org wrote:
wprov didn't seem to show up as a parameter in looking at the query field on an hour of logs on en.m.wikipedia.org via Hadoop, so I think we're okay there.
As for that additional data point, that's a good idea. Bernd, Dmitry, how about we do: sfi (image) and sft (text) ?
-Adam
On Tue, Mar 10, 2015 at 4:47 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
On Mar 10, 2015, at 11:26 AM, Adam Baso abaso@wikimedia.org wrote:
We're going to use the following format:
?wprov=<3_char_feature><platform_one_char><major_version_of_feature_uint>
For the first version on iOS, this will be
?wprov=safi1
And Android: ?wprov=safa1
Thanks for the closing the loop on this. Dan, Adam – have you guys considered tagging the type of “share”? I expect “image shares” will have higher engagement/click-through than “text shares”, if that’s a data point you want to collect explicitly, you’ll want to pass a different value to 3_char_feature (assuming that’s possible).
Is the new parameter going to be in the next beta build?
Dario
On Mon, Mar 9, 2015 at 1:39 PM, Adam Baso abaso@wikimedia.org wrote:
> Okay, we'll plan on wprov. > > On Wed, Mar 4, 2015 at 12:44 PM, Dan Garry dgarry@wikimedia.org > wrote: > >> Works for me. >> >> Dan >> >> On 4 March 2015 at 12:33, Adam Baso abaso@wikimedia.org wrote: >> >>> How about 'wprov'? >>> >>> On Wed, Mar 4, 2015 at 12:29 PM, Dan Garry dgarry@wikimedia.org >>> wrote: >>> >>>> I'd really rather this be either something that's totally not >>>> understandable by the user (e.g. ?saf=1), or something that is clearly >>>> understandable (e.g. ?appshareafact=1). >>>> >>>> Dan >>>> >>>> On 4 March 2015 at 12:26, Adam Baso abaso@wikimedia.org wrote: >>>> >>>>> Ha! I'm cool with 'provenance' if no one objects. >>>>> >>>>> On Wed, Mar 4, 2015 at 11:25 AM, Andrew Otto < >>>>> aotto@wikimedia.org> wrote: >>>>> >>>>>> Oof, only that it is ugly! :) >>>>>> >>>>>> Can you just call it ‘provenance', or are you trying to be more >>>>>> future proof? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mar 4, 2015, at 12:11, Adam Baso abaso@wikimedia.org >>>>>> wrote: >>>>>> >>>>>> I pinged on Phabricator at >>>>>> https://phabricator.wikimedia.org/T90606 about modeling after >>>>>> that patch. That sort of approach should avoid cache fragmentation. >>>>>> >>>>>> As for parameter name, 'wmfxan' is short and I think would >>>>>> avoid collisions. Any problems with this parameter name? >>>>>> >>>>>> -Adam >>>>>> >>>>>> >>>>>> On Thu, Feb 26, 2015 at 8:27 AM, Nuria Ruiz < >>>>>> nuria@wikimedia.org> wrote: >>>>>> >>>>>>> Ping ... (regarding cache question) >>>>>>> >>>>>>> On Tue, Feb 24, 2015 at 5:18 PM, Gergo Tisza < >>>>>>> gtisza@wikimedia.org> wrote: >>>>>>> >>>>>>>> On Tue, Feb 24, 2015 at 3:48 PM, Nuria Ruiz < >>>>>>>> nuria@wikimedia.org> wrote: >>>>>>>> >>>>>>>>> 2. What about caching? >>>>>>>>> Is this page:* >>>>>>>>> http://wikipedia.org/BarackObama?some_param=some-value >>>>>>>>> http://wikipedia.org/BarackObama?some_param=some-value* >>>>>>>>> being served from the cache as it should be? >>>>>>>>> >>>>>>>> >>>>>>>> The file download parameter was handled via this patch: >>>>>>>> https://gerrit.wikimedia.org/r/#/c/120617/ >>>>>>>> Seems like an analogous scenario. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dan Garry >>>> Associate Product Manager, Mobile Apps >>>> 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 >>> >>> >> >> >> -- >> Dan Garry >> Associate Product Manager, Mobile Apps >> 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