In Google Analytics I have dimensions available for hours and minutes. Is there an easy way to also have seconds?
I know that I could do custom dimensions, but I don't want to change my tracking code if possible.
Why I want this:
I search for the service provider (B2B customer) and want to track the steps (pages) a service provider did. I need this in chronological order and without seconds this is very inaccurate.
Inside Google Analytics this is not enable, but you can use code to extract this information from the computer (it's not the most accurate way because the second will based on the computer where the code is placed), but it can be an option for you
First you have to create a function to extract the second
function gaTime(){
var date = new Date;
return date.getSeconds();
}
and then use that on every desired hit, in this case, i used the code on the pageiew (you can replace this line for the one inside the main snippet placing the function before)
ga('send', 'pageview', {
'dimensionxx': gaTime()
});
Google Analytics does not offer agitation deeper then minute. You could technically do it yourself using a Custom Dimension. However this will not change the resulting data calculations.
there is currently an issue request for Ga:unixtime that might help with this but they have already stated that it wont aggregate down below minute.
Even if we are able to create this dimension the Analytics Reporting
API only reports data in aggregate and as such the finest grain
reporting would be minute
Related
I have 9 Google spreadsheets. Each of those files has 8 sheets. Each of those sheets has 1-5 importxml formulas that retrieves data from an api. Every api query uses costly credits, and leaving the importxmlformula as it is, uses way too much credits as it refreshes every 30/60min and i only need the data once a day.
So i added a named range with a refresh boolean. My google apps script sets this boolean at 6am to true, only if this is true, the importxml formulas work.
Example:
=IF(REFRESH = TRUE, IMPORTXML("https://api.sistrix.com/links.overview?" & API_KEY & "&" & DOMAIN, "//#num"))
Another google apps script, triggered an hour later, copies all the cell contents to another sheet an puts a date behind it, so i archived it for long term.
My problem tho, there are 300+ importxml formulas, triggered at the exact same time. A part of them are stuck in loading, an even an hour later, my archive script only copies #ERROR! values for those.
I tried using triggers for the scripts at different times, so i dont overload the api, but this didnt help. Then i added another refresh boolean to independently set a few importxml fomrulas at time X, and the other ones at time Y, but this didnt help either.
Do you have any ideas how i could increase the performance or how i could minimize the formulas executed at one time?
Thanks in advance
The way I have been doing it so far is to use Meteor.call and reset all the series in the callback, adding all the points all over. I then fetch new data using $interval every 5 seconds or so. This is obviously not very efficient and my data set is growing.
Now I'm trying to switch to a Meteor subscription since it feels like the right tool for the job.
The first challenge was how to add (a single time) all the points that are already in the collection. I solved that by using the onReady callback of a subscription.
Now my question is: how do I process the subsequent updates to the series on the chart?
I have a helper collection which is supposed to receive the updates and although this works transparently when used in an ng-repeat, I find it difficult to interact with outside of this use case.
I tried to $watch it but the watcher does not trigger.
The Higcharts documentation has a pure Meteor example on how to do what I want: http://www.highcharts.com/blog/195-meteor-standalone, but how do can I adapt it for angularjs-meteor?
Use ng-highcharts, and make sure your series is linked to the helper result.
I want to display a graphical report based on time (weekly/daily) which shows that what is the status of static code analysis over the period of time. E.g. vertical bar will denote number of issue and horizontal will display the time day/month/week. This will help to keep an watch of code quality easily over the period of time (something like burn down chart of scrum). Can someone help me for this?
The 5.1.2 issues search web service includes parameters which let you query for issues by creation date. Your best best is to use AJAX requests to get the data you need and build your widget from there.
Note that you can query iteratively across a date range using &p=1&ps=1 (page=1 and page size=1) to limit the volume of data flying around, and just mine the total value in the top level of the response to get your answer.
Here's an example on Nemo
Here's my scenario:
I have a page that contains a list of users. I create a new user through my web interface and save it to the server. The server indexes the document in elasticsearch and returns successfully. I am then redirected to the list page which doesn't contain the new user because it can take up to 1-second for documents to become available for search in elasticsearch
Near real-time search in elasticsearch.
The elasticsearch guide says you can manually refresh the index, but says not to do it in production.
...don’t do a manual refresh every time you index a document in production; it will hurt your performance. Instead, your application needs to be aware of the near real-time nature of Elasticsearch and make allowances for it.
I'm wondering how other people get around this? I wish there was an event or something I could listen for that would tell me when the document was available for search but there doesn't appear to be anything like that. Simply waiting for 1-second is plausible but it seems like a bad idea because it presumably could take much less time than that.
Thanks!
Even though you can force ES to refresh itself, you've correctly noticed that it might hurt performance. One solution around this and what people often do (myself included) is to give an illusion of real-time. In the end, it's merely a UX challenge and not really a technical limitation.
When redirecting to the list of users, you could artificially include the new record that you've just created into the list of users as if that record had been returned by ES itself. Nothing prevents you from doing that. And by the time you decide to refresh the page, the new user record would be correctly returned by ES and no one cares where that record is coming from, all the user cares about at that moment is that he wants to see the new record that he's just created, simply because we're used to think sequentially.
Another way to achieve this is by reloading an empty user list skeleton and then via Ajax or some other asynchronous way, retrieve the list of users and display it.
Yet another way is to provide a visual hint/clue on the UI that something is happening in the background and that an update is to be expected very shortly.
In the end, it all boils down to not surprise users but to give them enough clues as to what has happened, what is happening and what they should still expect to happen.
UPDATE:
Just for completeness' sake, this answer predates ES5, which introduced a way to make sure that the indexing call would not return until the document is either visible when searching the index or return an error code. By using ?refresh=wait_for when indexing your data you can be certain that when ES responds, the new data will be indexed.
Elasticsearch 5 has an option to block an indexing request until the next refresh ocurred:
?refresh=wait_for
See: https://www.elastic.co/guide/en/elasticsearch/reference/5.0/docs-refresh.html#docs-refresh
Here is a fragment of code which is what I did in my Angular application to cope with this. In the component:
async doNewEntrySave() {
try {
const resp = await this.client.createRequest(this.doc).toPromise();
this.modeRefreshDelay = true;
setTimeout(() => {
this.modeRefreshDelay = false;
this.refreshPage();
}, 2500);
} catch (err) {
this.error.postError(err);
}
}
In the template:
<div *ngIf="modeRefreshDelay">
<h2>Waiting for update ...</h2>
</div>
I understand this is a quick-and-dirty solution but it illustrates how the user experience should work. Obviously it breaks if the real-world latency turns out to be more than 2.5 seconds. A fancier version would loop until the new record showed up in the page delay (with a limit of course).
Unless you completely redesign ElasticSearch you will always have some latency between the successful index operation and the time when that document shows up in search results.
Data should be available immediately after indexing is complete. Couple of general questions:
Have you checked CPU and RAM to determine whether you are taxing your ES cluster? If so, you may need to beef up your hardware config to account for it. ES loves RAM!
Are you using NAS (network-attached-storage) or virtualized storage like EBS? Elastic recommends not doing so because of the latency. If you can use DAS (direct-attached) and SSD, you'll be in much, much better shape.
To give you an AWS example, moving from m4.xlarge instances to r3.xlarge made HUGE performance improvements for us.
I need to know the relative position of an object in a list. Lets say I need to know the position of a certain wine of all wines added to the database, based in the votes received by users. The app should be able to receive the ranking position as an object property when retrieving a "wine" class object.
This should be easy to do in the backend side but I've seen Cloud Code and it seems it only is able to execute code before or after saving or deleting, not before reading and giving response.
Any way to do this task?. Any workaround?.
Thanks.
I think you would have to write a Cloud function to perform this calculation for a particular wine.
https://www.parse.com/docs/cloud_code_guide#functions
This would be a function you would call manually. You would have to provide the "wine" object or objectId as a parameter and then get have your cloud function return the value you need. Keep in mind there are limitations on cloud functions. Read the documentation about time limits. You also don't want to make too many API calls every time you run this. It sounds like your computation could be fairly heavy if your dataset is large and you aren't caching at least some of the information.