I have 20 page load rules .
My question is do all page load rules execute on each page or only the rule related to that page .
Reason why I am asking is
when i have condition path contains and i hardcode the path or URL , in DTM debugger only the page load rule fires shows ,
whereas when i create a data element where i get value from page title and add condition to rule data element value = title ,
there it shows condition not met for all the other pages .
If i understand it correct then when url strings is defined as static it is not evaluating all page load rules ,
WIll evaluating all page load rules based on data element make the page slow or all rules evaluate anyways .
Thanks
All page load rules have their conditions evaluated on every page load. However, not all of them actually show a console log (a _satellite.notify() call) of it. because..reasons? Honestly, I don't know why it's not consistent but at one point I did dig into the core DTM library and confirm that it doesn't always make a _satellite.notify() call, based on stuff like you pointed out. And yeah, it's kind of annoying.
WIll evaluating all page load rules based on data element make the page slow or all rules evaluate anyways .
As mentioned, all of the page load rules will have their conditions evaluated on every page. This will impact page performance, sure. But the contents of a given page load won't actually be executed unless all of the conditions for the rule evaluates true.
And, whether or not the contents in a given rule are even (pre)loaded depend on how you setup the rule. Page load rules set to evaluate synchronously (page top/bottom) or have tags in them set to output synchronously will have their contents synchronously loaded, regardless of whether or not all of the conditions actually evaluate true (and if they are true, then it will be executed).
Related
Where do I make the initial function call to s_getLoadTime(). My library is being managed by Adobe.
https://marketing.adobe.com/resources/help/en_US/sc/implement/getLoadTime.html
Step 1: Add the plugin and timer start code
First, you need a Page Load Rule that is set to trigger at "Top of Page". If you already have an existing rule that triggers every page load at top of page, you can use that. If you do not, then create a new one.
Then, in the Javascript / Third Party Tags section, click on "Add New Script". Set the Type to "Sequential Javascript" and check the Execute Globally option.
In the code box, paste the following code:
// this is for older browser support
var inHeadTS=(new Date()).getTime();
// plugin
function s_getLoadTime(){if(!window.s_loadT){var b=new Date().getTime(),o=window.performance?performance.timing:0,a=o?o.requestStart:window.inHeadTS||0;s_loadT=a?Math.round((b-a)/100):''}return s_loadT}
// call plugin first time
s_getLoadTime();
Click on Save Code and then Save Rule.
Step 2: Make the 2nd call to plugin and assign to Adobe Analytics variables
Next, you need a Page Load Rule that is set to trigger at "Bottom of Page". If you already have an existing rule that triggers every page load at bottom of page, you can use that. If you do not, then create a new one.
Then, go to Conditions > Rule Conditions > Criteria and from the dropdown select Data > Custom and click "Add Criteria". In the code box, add the following:
_satellite.setVar('loadTime',s_getLoadTime());
return true;
Then within Adobe Analytics section of the rule, you can set your prop and/or eVar to %loadTime%.
Note: Using a rule set to trigger at "Onload" will technically be more accurate. However, DTM does not currently offer ability to trigger Adobe Analytics Onload (options are only for top or bottom of page), so if you set the rule to "Onload" it will trigger after AA has made a request so your variables will not be populated and sent in that request. If you really want to keep the accuracy then you will need to explore other options, such as implementing AA as a 3rd party script so that you have more control over when it triggers.
Click on Save Rule and then Approve/Publish once you have tested.
The question should really be, "Why should the getLoadTime() plugIn be used, ever?". Yasho, I started with the same question that you had and blindly implemented the plugIn in Adobe DTM following the instructions at https://marketing.adobe.com/resources/help/en_US/sc/implement/getLoadTime.html
Only after starting to analyze the data did I look into the plugIn to see what it does.
Below is the beautified code of the plugIn:
function s_getLoadTime() {
if (!window.s_loadT) {
var b = new Date().getTime(),
o = window.performance ? performance.timing : 0,
a = o ? o.requestStart : window.inHeadTS || 0;
s_loadT = a ? Math.round((b - a) / 100) : ''
}
return s_loadT
}
So, basically the function records s_loadT once and only once. The first call (way at the top of the page) sets the value and any subsequent call to the function will return that same value since it has been persisted in window.s_loadT
Scratch your head a bit and ask the obvious question, "So what does this measure anyway?" Best case, it measures the difference between window.performace.timing.requestStart and the timeStamp when the function was first called. Worst case it measures the difference between a timestamp set in the head of the document by javascript (and that difference could very well be a negative number). Or even worse if 'a' resolves to 0, you'll just get 'b' which will be a huge number.
If you are following the directions and calling getLoadTime() up high in the document (DTM page top rule), you're really just be measuring how long it takes to fire a page top rule. If you put the first call into the top of your s_code.js, you're just measuring how long it takes to load (and execute) s_code.js
My program flow requires that I first set the value of a select option in the Viewmodel and then I load the available options into the Viewmodel. This causes problems, typically the first available option will be seen in the selection list after this, while the selected option value stays at the specified value.
I was hoping that setting the new "valueAllowUnset" would help, but instead my page becomes unresponsive when using it.
Therefore I currently set the original value again after loading the options. Strangely, this only works when I set the value, set a different value and then set the value again, e.g.
self.data()[field](orgValue);
self.data()[field]({});
self.data()[field](orgValue);
(I store values for multiple selection lists in the self.data observable and access them with the property index "field".)
I tried to strip this down to a simple JSFiddle (http://jsfiddle.net/timvdh/HN6DE/), but the behavior does not show there, although the example pretty much resembles my actual application. However, I am using about 30 select lists there.
So I was hoping, that someone can make an educated guess about what goes wrong in my application, I am hoping that the fact that I have to set the original value three times maybe gives a clue.
EDIT: This fiddle demonstrates, that setting the selected option before and after filling the options list does work with "valueAllowUnset": http://jsfiddle.net/timvdh/HT5Tp/
I am using JQuery Mobile with knockout.js and that caused the problem (sorry I did not even think about JQM being the problem in the first place). I am now setting the option before filling the list and after filling the list I call
$("#selectmenuID").selectmenu("refresh");
to display the option.
The hanging browser was not caused by knockout, there are additional subscriptions to the selectmenus in my app. "valueAllowUnset" changed the behavior of the selectmenus and triggered loops caused by problems in my code.
My application feature a "main" page where most of the action happens: There are tags for filtering and a list of results in a (paginated) table, plus the possibility to select some or all results in a "shopping cart".
This page has to keep track of a whole lot of things: what tags are selected, what items are selected, and how the result table is sorted and what page it's on. Everything has to persist, so if I select a new tag, the page must partially reload but remember everything (sorting, what's selected).
Right now I'm handling everything with parameters, and for each action taken on the page, all links (select a tag/item, change page, sort table) are updated to include previous parameters + the relevant new addition. This works, obviously, but it feels kind of inefficient, as I have to reload more of the page than I want to. How is this situation normally handled? I can't find that much info on google at all, but it doesn't feel like a particularly uncommon case.
tl;dr: How to best make sure all links (to the same page) always include everything previously selected + the new action. There are a lot of links (one per tag to select/deselect, one per result item to select/deselect, one per sort option, one per page)
There are five ways to do that:
Method 1: By parameters
You mentioned this. I never think of this as it's too troublesome. Anyway it's still a solution for very simple case.
Method 2: By cookie
Save the settings to a cookie and read the cookie in controller to arrange layout settings.
Method 3: By LocalStorage
Similar to cookie but allows more space.
Method 4: By Session
If you are using ActiveRecord to save session, this could be the best solution for pure pages loading. Save the user preferences into session and load it in next layout.
Method 5: Use Ajax
This is the best solution IMO. Instead of whole page loading, use Ajax to refresh/retrieve changes you need. Using together with above method, a user can even continue his last preferences. This is the most powerful and should be applicable to your case which looks like a web app than a website.
Have you tried creating model for all those attributes? and just always load the 'latest' when on the page load, if you dont need them you can always have a flag for that session.
I'm planning out how to track internal search data in Omniture/SiteCatalyst.
It's a fairly straight-forward plan for a standard "enter a term and get a page of results" model: set sProps and eVars with the terms, the count of results, and the page searched from, then fire a success event for searching and another for clicking a search result.
For a type-ahead search--where the user is given search results as they type in a search bar--what's a good strategy for handling the timing of event submissions so that you don't end up with different events/entries for letters 4, 5, 6, and 7 of a search term's entry?
Our solution was to leverage a delay on the autocomplete to reduce the number of calls. From a tracking standpoint, if someone pauses for 1 second (or 500 ms, whatever), then they're probably actually waiting for the autocomplete results, and that constitutes a valid search.
From a technical standpoint, we leveraged the delay option on the jQuery UI widget.
Strategy I've always used is to not track the "auto-complete" search features..put the tracking on the search results page same as normal. Or are you saying the whole search results page is being output as the user types? If that is the case...one thing you could do is write some code to pop the Omniture code when the search field loses focus.
Another thing you can do is as the visitor is typing in the search bar, on each keypress, write the current value to a cookie. Then have some code that runs on page load to look for that cookie and if it exists, pop the Omniture search variables and erase the cookie. Alternatively you can keep track of current value w/ a server-side session variable since I assume this thing is ajax driven, and output the omn code w/ server-side code if session var exists. These methods would mean that the search events and vars would not pop on the search results page...this probably isn't that big a deal, unless you have supporting variables you pop, like an "internal search referrer" prop/eVar that keeps track of the previous page the visitor was on (or the page the visitor was on when they performed the search). So you'll have to keep that in mind and carry that over as well.
Whenever you do a search you might be aware of the concept that query string parameter get added at the end of URL.
Suppose www.stackoverfow.com is website and when are you performing a search on it then it will be like www.stackoverflow.com?q=yourname , yourname is the searchkeyword.This keyword we can capture in sitecatalyst.
you can see google.com while searching on internet for sitecatalyst is ---
www.google.co.in/search?q=sitecatalyst
In the same way we can use query string parameter as q = something.
after doing all this thing we can use the plugin getQueryParam in plugin section of the s_code library file to fetch that variable and store that in sitecatalyst variable...
example:-
function s_doPlugins(s) {
var one = s.getQueryParam("q");
if(one)
s.eVar1=one;
}
s.doPlugins=s_doPlugins
insert this below code outside plugin section
/*
* Returns the value of a specified query string parameter, if found in the current page URL.
*/
s.getQueryParam=new Function("p","d","u",""
+"var s=this,v='',i,t;d=d?d:'';u=u?u:(s.pageURL?s.pageURL:s.wd.locati"
+"on);if(u=='f')u=s.gtfs().location;while(p){i=p.indexOf(',');i=i<0?p"
+".length:i;t=s.p_gpv(p.substring(0,i),u+'');if(t){t=t.indexOf('#')>-"
+"1?t.substring(0,t.indexOf('#')):t;}if(t)v+=v?d+t:t;p=p.substring(i="
+"=p.length?i:i+1)}return v");
s.p_gpv=new Function("k","u",""
+"var s=this,v='',i=u.indexOf('?'),q;if(k&&i>-1){q=u.substring(i+1);v"
+"=s.pt(q,'&','p_gvf',k)}return v");
s.p_gvf=new Function("t","k",""
+"if(t){var s=this,i=t.indexOf('='),p=i<0?t:t.substring(0,i),v=i<0?'T"
+"rue':t.substring(i+1);if(p.toLowerCase()==k.toLowerCase())return s."
+"epa(v)}return ''");
you will find that it will capture your search results
please let me know in case of more clarifications
I'm looking for some non-javascript techniques by which to reload a page of tree items (basically divs within divs) while remembering their "show/hide" status. So far the only thing I can think of is to pass every entity's ID as part of a parameter list and have Rails then insert a "class-display" in the class list (or, of course, directly append the appropriate css) when the page reloads. In any case, is there a better way by which to manage these items?
Basically my goal is to be able to show/hide the tree whether JS is enabled or not.
Best.
I would seriously consider implementing this with cookies. It's not exactly critical data, as in the world isn't going to end if someone deletes a cookie and collapses their tree. It will also avoid having to spew state information all over your query strings.
When opening a new branch, your controller would add a new cookie that marks as "open" whatever div id needs to be expanded. Closing a branch would be the reverse -- controller deletes / modifies the cookie.
Then when rendering your view, use the cookie info to decide which divs should have their display style set to "normal" or "none".