General Questions  - 
Lookup table macros. Two quick questions:

1. Does the left column support Regex (it now says 'equal'). If not, are there plans to support it?

2. Does the right column (value) support referencing other macros or javascript (random example: {{ element id }} + ). If not, are there plans to support it?


Chip Oglesby's profile photoCarmen Mardiros's profile photoBrian Kuhn's profile photoEric Erlebacher's profile photo
Hi Carmen!

Here's what I know so far.

1) No, just an equal match evaluation. From what I understood of +Brian Kuhn's reply in an earlier discussion, there probably won't be any other form of evaluation for Lookup Tables. Part of the charm (and speed) of the lookup table is precisely because more complex predicate evaluation (like RegEx, partial match, < and >, for example) is left to rules and linked macros.

2) Both columns support macros, but no JavaScript since there's no <script/> context in GTM fields (other than Custom JavaScript and Custom HTML macros).
Thanks Simo. That's a shame on both counts but understand the reasoning behind it. Cheers. 
+Carmen Mardiros 

You can always use iMacro to bulk populate the lookup table (like a CSV import). 

Note: GoogleAccounts have been more aggressive preventing automated browser tools recently, so iMacro is not a good long term fix (i.e CSV import is better).

Here is an iMacro example script for {{url path}} >> {{pageGroup1}}.

Note2: There was a client requirement to use pageGroup1 client-side, rather than within settings hence lookup table and iMacro option was used...

'------ START iMacro

'  Go to first Tab

' Enter URL of you lookup macro

' NOTE: You will need to create a new CSV contains 3 headings index, url_path, pagePath1 (e.g. "0", "/folder/product0.html", "Folder")
'Path to file is C:\Users\user\Documents\iMacros\Datasources\
SET !DATASOURCE url_list.csv

'Nummber of heading colomns in the CSV
'Ignore first Row in CSV

'Loop until End Of CSV File
'------ END iMacro
The iMacro/GoogleAccount trigger threshold is a stream of 200 HTTP (new rows) requests.

So 200 row batches or wait 1 second delay etc, can be used as a work-around.
Thanks Phil, except I was planning to use it to create unique interaction keys which I can then match to a dictionary. The problem lies in the interaction key itself, for example, {{ element classes }} (one of the components of my key) often contains, not equals, the selector I need to match my interaction to a specific {{ event category }} value.

As it stands, lookup macro tables could still work for what I need, I just need to choose components that would always match exactly (i.e. {{ element id }} or {{ element name }} and not  {{ element classes }} which normally contains a string of selectors. Hope that makes sense. 

Carmen, I hear you loud and clear. That's a case where lookup tables won't do.

How about if you use a utility JavaScript macro in your tags, which retrieves the value of the lookup table exact matches, and if the lookup table returns "default" (or whatever you have for the default value if no exact matches work), the second macro would then cycle through the class attributes for a partial match and return that?

A bit more complexity, but it would eliminate the need to make a or if...else construct for the exact matches.
What I have been doing until now is use a key value JSON dictionary file with a default value it falls back on if the key isn't present in the dictionary. But that also relies on exact match.

I wonder, can you reference a macro lookup table in another macro lookup table? 
+Carmen Mardiros, yeah you can reference any type of macro in the available fields. I just did a simple test and it worked like a charm.
GTM may support a richer set of operators for lookup tables in the future.  For now, they're relatively easy to implement yourself using a custom JS macro.  

Create your table using an array.  Then iterate through that array looking for a match.  If no match is found, return a default value.  Here'e an example of implementing regex matching: 

function() {
  var input = {{macro_to_test}};

  var map = [
    [/foo.*/, "matches foo"],
    [/bar.*/, "matches bar"],
    [/baz.*/, "matches baz"]

  for (var i = 0; i < map.length; i++) {
    if (map[i][0].test(input)) return map[i][1]; 
  return "default value";
Thanks Brian, very helpful! Performance wise, what size a map would start affecting performance?

I'm in two minds about putting this map/dictionary in GTM itself or locally on the server along with the other resources.

Anyway many thanks! 
Re: "what size map would start affecting performance"

It's very complicated.  There are too many variables to give a simple answer to this.  The nature of your input, the regular expressions, the return values, levels of macro references, and the browsers you're targeting will all affect performance.  Testing is probably the only way to reasonably estimate how your code will do.

The normal size limits in GTM should keep you in bounds in terms of code/download size.  So I guess we can focus on execution speed.  Tools like JsPerf are great for measuring things like this.  You can create tests, and run them in various browsers to see how your performance degrades in relation to the size of your map.  I've created an example test here with 1, 10, 100, and 1000 entries.

And...once you know exactly how your code should behave, the patterns you'll be using and the output, there are other performance optimizations you can make.  For example, if your map is static (no dynamic macro references), you can probably memoize/cache the results, so that multiple calls for the same input will perform better.
+Phil Pearce Thanks so much for that recommendation, it works perfectly! Well, almost perfectly... +Brian Kuhn I get the following error when trying to save my changes to the lookup macro: "Internal error. Please try again later." I get this error even when trying to cancel/leave the changes I made to the macro. When I refresh the page, I am logged out of my Google account.

This is repeatable even with just a few entries, though I'm concerned about the number of rows (210). Is this error related to the number of entries, using iMacros, or something else? 
This problem was isolated to Firefox; it was not repeatable in Chrome.
Add a comment...