6 Replies Latest reply on Apr 13, 2016 4:43 PM by prendek

    Variables for Analytics with Adobe SiteCatalyst (Omniture)




      I'm trying to return the container name to SiteCatalyst.  I'm using a statement that support found for me to assign the container (space) name to a variable. Here's the string:


      var gPlaceName = "${container.name}".replace(/'/g,"");

      s.prop10 = gPlaceName;


      I implemented this with the help of support, and in SiteCatalyst, all hits on content are reporting back under the variable s.prop10 and giving me a result that looks like ${container.name}


      I think I need a bit of help to make sure I get the variable name vs string value correct here. Before I iterate support too much more, is this the correct way to code it to report the container name? (Basically eliminating the quotes around container.name)


      var gPlaceName = ${container.name}.replace(/'/g,"");

      s.prop10 = gPlaceName;







        • Re: Variables for Analytics with Adobe SiteCatalyst (Omniture)

          Hi Ryan Rutan,


          I've seen your comments on some of the analytics discussions. Is there someone on your team that could help with my question? I just want to make sure I get the syntax right for the container name variable before I have support post it again.



          Pete Rendek

            • Re: Variables for Analytics with Adobe SiteCatalyst (Omniture)
              Scott A Johnson

              Hey Pete,


              Is this in a ftl file? soy file?



                • Re: Variables for Analytics with Adobe SiteCatalyst (Omniture)

                  Hi Scott,


                  Sorry for the brevity - it's a part of the page code - it's in a modified Adobe javascript used to return analytics to SiteCatalyst.



                    • Re: Variables for Analytics with Adobe SiteCatalyst (Omniture)
                      Scott A Johnson

                      Oh, gotcha. In that case I'm not sure how to properly reference the name.

                        • Re: Variables for Analytics with Adobe SiteCatalyst (Omniture)
                          Ryan Rutan


                          Since this is SiteCatalyst, you are running standard javascript.  When you put anything inside quotes like that, it is treated as a literal, so I expect that SiteCatalyst is doing things right.


                          Some caveats before I share some ideas,

                          • Using JS environment variables in Jive is a bit risky as they may not be around in future versions...that being said, there are two that have been around for quite some time
                            • containerID and containerType

                          If you wanted to try and change your code to:

                          if (containerID && containerType) {

                               s.prop10 = containerType+"-"+containerID;

                          } // end if

                          When present (usually present on place page views and content), it would populate your s.prop10 variable.  I would imagine coverage would be at-least 80-90% ... meaning these variables may not exist on some random sub-space views, but they cover most of them.  More importantly, when they are there..you can trust they are accurate.


                          This will give your string a value similar to "14-4340" (which) is the value for this space in our community.  This will uniquely identify the place in Jive, but it is not "human readable".


                          To get to the name, there are a few ways,

                          • inspect the DOM for a standard location, such as something in
                            • s.prop10 = $j('#js-breadcrumb-intro').data('container-display-name'); // WHEN VIEWING CONTENT
                              if (!s.prop10) s.prop10 = $j('a.j-placeName')[0].text; // WHEN VIEWING A PAGE FOR A PLACE
                              if (s.prop10) .replace(/'/g,""); // OR ADDITIONAL DATA CLEANSING AND ERROR CHECKING
                              • Note:  Has a dependency on jQuery (not a bad thing, but it is worth pointing out)
                              • Note:  Assumes that the ID of the UI elements will not change.  If the ID or selector classes were to change, or the data-attribute, then this would fail to find the values.
                              • Note:  Because there are so many views, you may find that this doesn't cover them all, but this means you could just add my conditions to the chain.  I'd order them in the order of most likely to occur as a general rule of thumb (based on historical page traffic)
                              • Note: Minimal maintenance once it is setup, incremental testing every upgrade.  Will work for existing and new places after setup.
                          • Usually tools like Site Catalyst have a translation file you can manage which take a property code (i.e. 14-4340) and translate it to a known value with a lookup index you manage in the remote tool.
                            • If you did this, you could easily pull the list of places that includes Type/ID/Name and create this list to manage in SiteCatalyst.
                            • Note: This one is less technical, but requires updates to the lookup table in the remote tool if new places are added that you want to track.  If you dont update the translation, the tool will show xx-yyyy as the "Place name" in reporting until the translation is provided.


                          Hopefully that helps... =)

                          2 people found this helpful