[06:55:55] Ironholds: around? [21:13:44] YuviPanda, now around [21:13:48] I'm getting a premonition... [21:13:51] *puts hand to forehead* [21:14:00] you have thoughts about...yes...eventlogging...and...apps! [21:14:10] * YuviPanda slaps some freebased butter on Ironholds's hand [21:14:24] I thought we'd agreed you'd stop going on about that ;p [21:14:28] anyway; what's up? [21:14:46] Ironholds: so, toby asked me to check up with you on something. [21:14:47] Ironholds: https://trello.com/c/NsCra66X/1-5-event-logging-editing-signing-in-article-navigation [21:15:08] Ironholds: it's your sunday evening so feel free to tell me to fuck off whenever :) [21:15:18] it's 2pm [21:15:20] Ironholds: so what are you using to track 'sessions'? IP / UA? [21:15:26] Ironholds: that's... afternoon, right? [21:15:26] but I would appreciate dealing with it on Monday ;p [21:15:29] yep [21:15:31] Ironholds: ah, it can wait! [21:15:38] so, I have looked at the schemas [21:15:48] woo! [21:16:04] would you like the 30 second or 30 minute rant on how nobody understands how to track sessions? ;p [21:16:12] actually, more productively: how are you guys defining a session? [21:16:15] app open to app close? [21:16:46] Ironholds: pretty much. [21:17:03] Ironholds: on android I'll probably define it as 'when the user has been away from the app for X minutes' since android has true multitasking [21:17:10] Ironholds: and it is fairly trivial to implement. [21:17:38] *winces* [21:17:41] oh dear. [21:17:53] you know, the industry standard is 30 minutes. [21:18:04] lack of activity for 30 minutes == end of session. [21:18:07] been in use since 1994. [21:18:11] I see [21:18:14] the reason for this is that the paper justifying it was in 1994. [21:18:19] hahaha [21:18:23] and it has been used, ever since, with no support [21:18:27] righg [21:18:28] right [21:18:32] 30m does sound like a fair bit. [21:18:33] http://blog.ironholds.org/the-myth-of-the-30-minute-session-timeout/ may interest you [21:18:37] hahah [21:18:49] So, my recommendation would be that we avoid defining X. [21:18:58] for the time being [21:19:10] because any definition we come up with in the absence of observing user behaviour is going to be wrong. [21:19:22] right. [21:19:48] I have some thoughts on how we could do it better (I have spent the last 2 months of my life doing nothing except reading every previous work that touched on sessions, and arguing with them, and doing research on our requestlogs, so this is sort of a hobby-horse for me) [21:20:04] :D do tell! [21:20:28] so, what we could do is have an interim schema that for...let's say 2 weeks, captures two things [21:21:06] (1) the timestamp in Y-M-D-H-S of every action a user takes. We don't care what the action is. [21:21:24] if you guys can track scrolling and such without it being horrifically creepy, that'd be great [21:21:30] (2) a unique identifier for that device [21:21:34] I don't care what they're doing, or where. [21:21:41] I care about the time intervals between their actions. [21:21:54] because then we can do expectation maximisation [21:22:01] I just got to that part of your blog [21:22:05] heh [21:22:07] and yes, we can do both very easily. [21:22:10] same principle, yep. [21:22:12] and without being creepy [21:22:20] since we don't know who they are or what they're reading [21:22:20] "If users haven't moved in X seconds, they're not coming back" [21:22:27] "solution: sessions end when a user hasn't moved for X seconds" [21:22:41] but I'd like to define X from the data, rather than the other way around [21:22:42] and I can make sure that (2) isn't tied to any other logging we do [21:22:45] right. [21:22:45] gooood. [21:23:03] also, can someone explain to me why you guys are using username as a unique identifier? [21:23:04] so you can't de-anonymize by cross-referencing [21:23:16] oh, you still could [21:23:20] Ironholds: because that's what we have 'easily available' in the app? :) [21:23:27] it just wouldn't be useful because you just have the timestamp available, nothing else. [21:23:34] Ironholds: indeed. [21:23:36] I can think of an easy way to cross-reference [21:23:51] how so? with just TS and a 'something happened!!!1' ping [21:24:00] sure, because 'edit' is an action. [21:24:20] If I take data associated with a user and work out that they're the only mobile editor whose timestamps of 'actions' line up with edits made by a single other user.. [21:24:30] but that'd, again, be pointless, because what are you going to get out of it [21:24:50] "I know that User:Ironholds has a session length 15 seconds below the median! bahahahahaah! fools!" isn't really very useful.] [21:25:17] hehe [21:25:38] by record 'every action' do you literally mean every action or just every *read* action? [21:25:47] like scrolling, navigating, tapping edit [21:27:06] the latter'd be useful, the former would be fine too. [21:27:13] I mean, the former is all I had for my mobile web session analysis [21:27:27] I'd be really interested in seeing if the latter lines up with the former, though. [21:27:38] Ironholds: every read action is easier for me to do. [21:27:48] then sure, go with that [21:28:45] Ironholds: alright, so every time someone 1. clicks a link, 2. scrollEnds I ping [21:28:50] (1) covers tapping the edit link too [21:29:07] Ironholds: this won't cover things like spending time actually editing, for example. Would that fuck up analysis? [21:29:39] naw, that's fine. [21:30:03] Ironholds: I can do that too, but would be a bit more gruntwork [21:30:22] Ironholds: I also need to know if our servers will not keel over from that much activity (scrollEnd sounds like it'll generate a lot) [21:30:32] then don't bother with scrollENd [21:30:35] link-clicking is fine. [21:31:38] hmm, I can batch scrollEnds [21:31:52] 'send when there's no scrollEnds for the last 10s' [21:31:58] or somesuch. That should give you accurate data too [21:32:35] let's just go for link-clicking to start with [21:33:04] I already have an inter-time analysis framework from my work for Mobile Web, so I can do the analysis as we're going and let y'all know if there's something screwy about it [21:33:10] simple data first, then complex data if the simple data justifies it [21:34:38] alright [21:34:41] so [21:34:51] 1. I generate a unique per-Device ID that's not used *anywhere* else [21:35:00] 2. I send an EL ping everytime clicks a link [21:35:06] 3. ?? [21:35:08] 4. profit [21:35:11] sounds good to me. [21:35:19] (3). I will build a kill switch for this feature so that if even *this* kills our servers we can immediately turn it off [21:35:31] (we have kill switches for a bunch of things) [21:35:33] hah [21:35:48] sounds good. But we should sit down this week and talk about how/why/what you guys are really interested in. [21:36:03] Ironholds: sweet. can you respond on the trello card whenever you feel like? I'll get to work on it now. [21:36:08] Nice sunday night post drink small hack. [21:36:37] sure [21:38:36] Ironholds: and no accounting for *which* event we are tracking, right? no 'linkClicked' vs 'scrollEnd' distinction? [21:40:35] Ironholds: also what format do you want the TS in? And should they be client side TSs or the default server side ones? Server side ones might be inaccurate because of network delays and stuff and also because we might have queuing in the app and EL pings will be prioritized to be less urgent than actual content [21:42:18] YuviPanda, I thought we were just tracking linkClicked? [21:42:28] and client-side sounds better in that case [21:42:32] alright. [21:42:41] yeah, true. so nevermind, it was a stupid question. [21:43:21] Ironholds: ISO dates? [21:43:58] sure, that's fine [21:44:13] ISO/POSIX-to-mediawiki was, I think, the first function I wrote that I still use ;p [21:44:18] :) [21:46:08] Ironholds: https://meta.wikimedia.org/wiki/Schema:MobileWikiAppReadingSession [21:47:16] seems good [21:47:23] Ironholds: ok! [21:48:42] Ironholds: renamed it too! https://meta.wikimedia.org/wiki/Schema:MobileWikiAppReadingAction [21:49:27] cool! [21:50:10] Ironholds: re why track: https://www.mediawiki.org/wiki/Event_logging/MobileApp [21:50:42] huh [21:51:00] okay, this may require a meeting, but I'll talk to toby first to see which bits of it he wants me to take on. [21:51:38] oh [21:51:47] you mean the analytics parts of figuring the answers out later on? [21:52:53] yeah [21:53:01] or are you guys mostly interested in just getting the schemas sensible? [21:53:29] me, I'm interested in getting the schemas sensible so they won't be a pain in the ass to analyse later on [21:53:47] since with the app updates aren't as easy as flipping a switch and getting new JS delivered [21:53:53] *nods*