Hi Analytics team,
I'm curious, which tools developed by Analytics have contributed notably to
editor engagement successes?
Pine
___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
Yes, getting EL data into labs would support longer term EEVS goals, and
I'm trying to focus on EEVS features we can release this quarter.
On Wed, Aug 13, 2014 at 3:56 PM, Dario Taraborelli <
dtarabore...@wikimedia.org> wrote:
> (expanding on what I think Dan is referring to re: goals), addressi
(expanding on what I think Dan is referring to re: goals), addressing this
issue would allow EEVS to access data needed to generate breakdowns for metrics
by method/target site (mobile, desktop, apps).
On Aug 13, 2014, at 1:40 PM, Dan Andreescu wrote:
> Kevin, for what it's worth I don't think
Kevin, for what it's worth I don't think that bug that Sean is asking for
is that challenging. The relevant part we'd have to change is really just
a few lines [1]. I respect your decision of course, but I just wanted to
point out that this issue does drive towards some of our goals, as we
talked
OK. Sounds reasonable. Sorry to seem as though I am pushing on you & the
devs. In fact, specifying that you won't have the bandwidth to even
consider the bug until next quarter gives me the power to push on others.
>:)
Thanks!
-Aaron
On Wed, Aug 13, 2014 at 8:56 PM, Kevin Leduc wrote:
> Hi
Nice post about using Samza at LinkedIn:
http://engineering.linkedin.com/stream-processing/moving-faster-data-streams-rise-samza-linkedin
___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
Hi Aaron,
I was not planning on prioritizing any EventLogging work for the rest of
this quarter. The analytics dev team has a goal to get an EEVS dashboard
running and I want to keep them focused otherwise we will not reach this
goal.
I'm tempted to ask what springle and YuviPanda can accomplish
Excellent. Kevin, can you work to get that bug[1] prioritized and let us
know? I can start working with R&D on a proposal to bring to legal.
1. https://bugzilla.wikimedia.org/show_bug.cgi?id=67450
It stands to reason that you would be interested on the capsule too as it
> holds the timestamp a
> Re. (2), I didn't say anything about that being related to
public/private.
> This is a request from springle -- that if we are going to start pushing
> Events to LabsDB, he'd like us to do so more efficiently. That bug is
about efficiently batching inserts.
ah, my mistake. Kevin can do prioritiz
Re. (2), I didn't say anything about that being related to public/private.
This is a request from springle -- that if we are going to start pushing
Events to LabsDB, he'd like us to do so more efficiently. That bug is
about efficiently batching inserts.
I don't know what you are talking about re
Aaron,
>(2) https://bugzilla.wikimedia.org/show_bug.cgi?id=67450
The bug does not have to do with making data public. It has to do with how
data is inserted in to EL from the
consumers, so it deals with the 'system', not the 'data'. The raw data as
inserted cannot be replicated directly to be made
Hey folks,
We've been discussing ways to make more Wikimedia data public. One of our
sources for data is EventLogging (EL)[1], a system that lets us track
events on both the client and server-side. Recently, YuviPanda and
springle have been working with us to figure out what issues need to be
re
Hi,
On Thu, Aug 07, 2014 at 03:59:13PM +0200, Christian Aistleitner wrote:
> we'll soonish purge the following tables from
> the EventLogging databases:
>
> SignupExpAccountCreationComplete_8539421
> SignupExpAccountCreationImpression_8539445
> SignupExpCTAButtonClick_8102619
> SignupExpC
13 matches
Mail list logo
