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 <gti...@wikimedia.org> wrote: > > On Tue, Feb 24, 2015 at 9:48 AM, Adam Baso <ab...@wikimedia.org > <mailto:ab...@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
