How not to develop a Campaign in SiteSpect

The following is an example of a use case and how developers that are new to SiteSpect might be temped to "code it".

You have a requirement for a new Campaign

• Redirect to a new page
• Alter the style of some elements on the new page

How you might be tempted to (but please don't)

• Inject a bit of JavaScript near the top of the page like
  

  window.location.href="/newpath/newpage.html"; 

• On the destination page, change the style like

  document.querySelector("#navTrigger").style.display = "none";
  document.querySelector(".m-supernav-logo").style.width = "10.4em";

Since SiteSpect has direct access to traffic, INSTEAD

• Use a Type: Origin > Type: Redirect Variation
  
  
  This is the most performant way to do a Redirect. It will redirect the page on the request before it gets to the Origin.
  Note: if your Triggers need access to page source, you can use a [Response] Redirect, which is still performant.
  
  For more information, see Redirecting a page; what type to use
• Inject a block of CSS in a <style> block inside the head with a Search and Replace Variation

  <style>
  #navTrigger { display: none; }
  .m-supernav-logo { width: 10.4em; }
  </style>
  </head>

• Optionally use Search and Replace to remove the HTML that you don't want and/or inject inline CSS into the elements.
• If you want to make other types of changes to elements that get created by a script in the page (after the page is delivered to the browser), consider using a Client Side Variation. This can work well for elements are are not yet created or otherwise ready when the page loads and it avoids the use of setTimeoout() for example. For more information, see Defining a Client Side Variation.