skip to main content

TAMU Webmaster's Blog

Information and insight from the A&M Webmasters

Using GTM to block test and dev sites

August 28th, 2017 by Erick Beck

I would guess that few of us remove our Google Analytics or Tag Manager calls from our site code when it is on a test or development server.  Depending on your setup, this could mean that hits to these environments increment (and distort) the analytics for your production sites.  A simple use of a blocking exception can prevent this.

This process is even simpler than previous examples since we don’t have to use a GA variable at all. Here, we just set up a blocking trigger that fires when the page hostname contains “test” or “dev” or whatever string you use to differentiate your test environment from production.   Then add this trigger as an exception on your site’s tag and none of your test/development sites will add to your analytics count.

Monday, August 28th, 2017 Uncategorized No Comments

Blocking Triggers Refined

August 23rd, 2017 by Erick Beck

In my last post about blocking triggers I showed how you can use exceptions to prevent Google Tag Manager from firing particular tags.  Because the HotJar tag contains the service ID value for that site we had to create individual tags/triggers for each site.

But what about when you have a more generic tag that is not linked to a particular service ID?  For example, you want to include an HTML or javascript snippet, but you still want to be able to control which sites it is or is-not displayed on.  You could create individual tags/triggers for each site as we did with HotJar, but there is actually a better solution.

The process starts the same, by adding a variable to your GTM.  This time, though, we will use the “Custom Javascript” variable type instead of the “Constant.”  The javascript we use then sets the URL of all of our sites that we want to exclude into an array.  It then loops through the array and tests whether the page being viewed is in that array.  If it is, then the function returns “true.”

At that point we can continue the same process that we showed for the HotJar tags.  Add a trigger that executes when the variable value returns “true” and then make that trigger an exception.  Now you are excluding that tag from firing only on the sites that you put in your javascript array.  To add or remove sites, just update the array in the variable and republish your tag workspace.

There are several other variable types. I have barely scratched the surface.  DOM Element looks particularly interesting.  This or another combination might actually solve the problem of needing duplicate tags for our HotJar implementation.  I will let you know if we ever get that far.


Tags: , ,

Wednesday, August 23rd, 2017 Analytics No Comments

Blocking Triggers in Google Tag Manager

August 17th, 2017 by Erick Beck

In looking at how to optimize our sites download time, one common recommendation is to combine all javascript into a single file.  An even better piece of advice – if there is javascript that your site doesn’t need, don’t download it in the first place.

One of the areas that we identified as being bloated was how we ran our HotJar heat map implementation through Tag Manager.  HotJar tags require an individual id number corresponding to the site being monitored.  Since we have several dozen sites, that means several dozen tags.

The default for tags is to run on all pages.  This meant that all of our sites were firing off all of the HotJar tags, regardless of whether they were even for the proper site.  Realistically that might not amount to much, but I knew we could do better.

One solution might have been to create different triggers for each site, but that would have quickly become unwieldy.  After stumbling across an article talking about trigger exceptions I decided to go down that route.  I first created a variable “Block Sites” with the value of “block” (it could have been “1” or “true” or whatever.)  From that I created the trigger “Block All Sites” that consisted of the simple comparison “When Block Sites = block” (in essence, “when 1=1”.)   The key is to then add this as an exception to your exiting tag firing triggers.  So the tag fires normally if the exception is not present, but does not fire at all if the exception is present.

In theory, since exception prevents the tag from firing, your page never downloads and runs the code associated with the tag.    We do not continually run HotJar, so we can keep the exception in place until we are ready to start collecting data. Then all we have to do is edit the tag to remove the trigger exception and publish the new version.

I do believe there is another way that eliminates even this through the use of an all-javascript trigger, but I’m not myself adept enough with javascript to get all the pieces put together.  I will post at least the first part of the process in a later post that doesn’t include the requirement to match the HotJar id value.

Tags: , ,

Thursday, August 17th, 2017 Analytics No Comments

Retiring domain

August 14th, 2017 by Erick Beck

Please be aware that in the near future – sometime in the Fall – we will be retiring the domain.  This does not mean we are retiring the central Google CSE search; it will still be available at

The domain is a holdover from previous iterations of the campus search, and has been largely unused for some time.  I looked through log files and it is getting very little traffic compared to For the sake of reducing maintenance and overhead, we have made the decision to remove the service from that URL.

So those of you who still do have a search box that points to, please go ahead and start migrating the code for your forms.  I will let you know once we have a firm shut-off date.

Tags: ,

Monday, August 14th, 2017 Search No Comments

Retiring Campus Tours Website

August 10th, 2017 by Erick Beck

Please be aware that in the near future we will be retiring the Campus Tours website at  Everyone working on this site had the best of intentions, but implementation never lived up to expectations.  With the content growing stale and the site not aligned with the brand, it is time to take it down.

A new virtual tours project will be started, but in the meantime anyone whose pages are still linking to this site should update the links to the current panorama tours that we have in the Campus Bird map implementation –

Tags: ,

Thursday, August 10th, 2017 Ongoing Projects No Comments

Website Optimization

August 8th, 2017 by Erick Beck

After being online for two years, we had noticed the university website starting to take longer to load.  We have therefore started a project to identify any bottlenecks and start re-optimizing the site for speed. As we identify issues we are also making adjustments to our other sites to maximize our users’ experience.

We won’t claim to have done anything extraordinary.  There are hundreds of websites that detail the steps you need to take, many online services that will analyze your site and offer suggestions, and even Google Chrome has much of this built in.

A few things we noticed:

  • Server settings are easy to verify and reset if necessary.  Things like compression and enabling browser caching are straightforward.
  • Optimizing images sizes should be an easy thing, but was our biggest point of failure.  Over time and as responsibilities shifted, saving images for the web somehow got dropped from the workflow.  Coupling this with having to produce larger images to look good on high-resolution screens only made the problem worse.
  • Today’s use of CSS and Javascript frameworks leads to a lot of bloat.  Many classes and functions are included but never used.  Even concatenating into a single file and minimizing can be problematic when every page needs a different combination of scripts included in the package.

Our process isn’t complete, and we will probably never be able to make all of the “recommended” improvements, but we have seen a definite improvement.



Tuesday, August 8th, 2017 No Comments

Personal Directories on University Website

August 1st, 2017 by Erick Beck

After several years and three turnovers in leadership, we have finally been able to make progress in removing personal directories from the university website.  Today we took the first step in this – adding a robots file that blocks these directories from search engines.  On November 1 we will be removing them altogether. My thanks to those of you who have worked with us in this process, particularly those who helped us find new hosting environments for faculty within your college.

Tuesday, August 1st, 2017 No Comments

Veteran Resources Hub

June 6th, 2017 by Erick Beck

Today we launched a page that has been on our to-do list since publishing the university page over a year ago.  We now have a dedicated Veteran Resources page.

We have several offices across campus who serve our veterans.  The purpose of this page is to elevate all of these content areas so that there is a quick and easy place to find resources – all the way from the admissions process through post-college careers.

This page will have a link front-and center on the university website, hopefully enabling those who serve to immediately find where to go for what they need.

Tuesday, June 6th, 2017 No Comments

New Student Conference 2017

June 5th, 2017 by Joe Prather

New Student Conferences (NSC) app welcomes new students and family members to Aggieland. This is the first year NSC was included in the TAMU app and also the first time we have used the Modo Labs Agenda Module. The Agenda Module lets us import events from a single Google Spreadsheet CSV file. This specialized calendar for NSC is for multi-day events, with support for multiple tracks and personalized user schedules. We look forward to helping users and events like NSC with the TAMU app in the future.

Monday, June 5th, 2017 Uncategorized No Comments

Why we need Solr?

May 18th, 2017 by Laith Albarakat

Apache Solr is a java based open source enterprise search platform. Many of web applications have some form of text searching. Given the fact that most applications are based on MySQL, the normal approach is to use some sort of SQL ‘LIKE’ query.

So, why we need Solr?

  • Performance: Solr is faster than using MySQL comparison, it achieves fast search responses because, it searches an inverted index not the text directly.
  • Scalability: Sorl can be setup on different sever from web/database server. Which allow search functionally to scale independently from your web/database servers.
  • Smart Searching: Solr has the ability to handle spell check and correction, auto suggest, results highlighting, similar key word suggestions, facet navigations, synonym search results, and much more.

Apache Solr is proven in terms of search engine, it has all the core features to perform any type of search functionality. Solr has been widely adopted, also it has a large community of supporters. For more information about Solr, please check


Thursday, May 18th, 2017 Uncategorized No Comments