Closed
Bug 1024946
Opened 10 years ago
Closed 10 years ago
Client needs to report clicked URLs
Categories
(Hello (Loop) :: Client, defect, P1)
Hello (Loop)
Client
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: RT, Unassigned)
References
Details
(Whiteboard: [p=?])
When the Firefox client will be used to initiate calls when clicking a URL we will need to report the data related to the clicked URL. For clarity the required data is: * Unique number of clickers daily (Users) * Number of instances of OS types daily * Number of instances of browser types daily * Number of users per country daily * New VS returning clickers (%) daily
Updated•10 years ago
|
Whiteboard: [p=?]
Target Milestone: mozilla34 → mozilla35
Comment 1•10 years ago
|
||
pushing to Fx35
Reporter | ||
Comment 2•10 years ago
|
||
Katie, can you confirm if this is now covered by 1061999?
Flags: needinfo?(kparlante)
Comment 3•10 years ago
|
||
Yes, the data generated for "clicked urls" data in the dashboard is tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1061999 A couple of comments about the original requirements above: - We can't do "unique clickers" or new/returning clickers because we don't have identifying information about the clicker. - We do have the data for OS/browser/country, and can see it in kibana, but we're not currently showing it in the dashboard. - We can identify unique users who *generate* call-urls though, which we should probably do instead of collecting the total hits to that endpoint. Also, we actually have two data points for "clicked urls": - When a user clicks the url, it invokes the web client (call.mozilla.com), which hits a loop-server enpoint to get information about the call token. We're counting this loop-server endpoint to represent "clicked urls". - If the user hits the "green button" to initiate the call, it hits a loop-server endpoint to initiate the call. We should count these as well. The difference between the two suggests the number of people who click on the url but don't go on to make the call.
Depends on: 1061999
Flags: needinfo?(kparlante)
Comment 4•10 years ago
|
||
based on Katie's input - is this closable for now? do we have the info we need - or enough to make some decisions.
Flags: needinfo?(rtestard)
Target Milestone: mozilla35 → ---
Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Katie Parlante from comment #3) > Yes, the data generated for "clicked urls" data in the dashboard is tracked > here: https://bugzilla.mozilla.org/show_bug.cgi?id=1061999 > > A couple of comments about the original requirements above: > - We can't do "unique clickers" or new/returning clickers because we don't > have identifying information about the clicker. OK that's fine > - We do have the data for OS/browser/country, and can see it in kibana, but > we're not currently showing it in the dashboard. Is there a way to have at least an export of this data? It will help make some decisions regarding timing for mobile form factor support VS IE or Safari support. > - We can identify unique users who *generate* call-urls though, which we > should probably do instead of collecting the total hits to that endpoint. > That's a good point, I created bug 1087952 to track > Also, we actually have two data points for "clicked urls": > - When a user clicks the url, it invokes the web client (call.mozilla.com), > which hits a loop-server enpoint to get information about the call token. > We're counting this loop-server endpoint to represent "clicked urls". > > - If the user hits the "green button" to initiate the call, it hits a > loop-server endpoint to initiate the call. We should count these as well. > The difference between the two suggests the number of people who click on > the url but don't go on to make the call.
Flags: needinfo?(rtestard)
Reporter | ||
Comment 6•10 years ago
|
||
I am closing this now and will follow-up with Katie via e-mail regarding the export for countries/OS/browser type.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•