There’s been a lot of buzz recently about the lack of secu­rity asso­ci­ated with client-side test­ing and opti­miza­tion solu­tions. These sus­cep­ti­bil­i­ties can leave orga­ni­za­tions’ test­ing strate­gies, cre­ative rota­tions, and even his­toric vari­a­tions exposed—sitting open in the page’s source code—for com­peti­tors and inquis­i­tive mar­keters to see. The cul­prit isn’t JavaScript in gen­eral (despite what some might have you believe), it’s one of the draw­backs of client-side archi­tec­ture, and one of the many rea­sons we’ve invested in a server-side approach for Adobe Tar­get.

The basic dif­fer­ence between server– and client-side archi­tec­ture is sim­ple: server-side sys­tems per­form oper­a­tions on remote servers and deliver the results back to a user’s local com­puter (the client), whereas client-side sys­tems exe­cute processes on the user’s com­puter itself.  Adobe’s global net­work of edge servers enables us to make con­tent and expe­ri­ence deliv­ery deci­sions on the server side.  The browser sends rel­e­vant infor­ma­tion to Adobe Tar­get, which returns the right con­tent to the right user at the right time. This archi­tec­ture ensures that Adobe can sup­port the round trips (from client to server to client) quickly and effi­ciently. Rel­e­vant con­sumer expe­ri­ences shouldn’t lag, and this infra­struc­ture enables seam­less deliv­ery while lever­ag­ing the most up-to-date infor­ma­tion for decisioning.

What’s more, server-side archi­tec­ture enables com­pa­nies to lever­age robust inte­gra­tions with data col­lec­tion and report­ing sys­tems, as well as with third-party data providers. This type of infra­struc­ture read­ily facil­i­tates cross-system user data mapping—a sin­gle user ID can exist across all systems—leading to con­sis­tency in report­ing and attri­bu­tion, as well as flex­i­bil­ity in tar­get­ing and audience-level per­for­mance analy­sis. With a client-side approach, you’re likely to encounter sig­nif­i­cant dis­crep­an­cies between sys­tems, and suf­fer from brit­tle con­nec­tions that often break when changes are made in either one.

As for those secu­rity con­cerns, another ben­e­fit of server-side archi­tec­ture is that it min­i­mizes the com­mu­ni­ca­tion from server to client, send­ing through only what’s required.  With client-side sys­tems, the server must send all pos­si­ble con­tent options to the browser, so the client can decide what to serve.  This is where the vul­ner­a­bil­ity arises—this trans­fer enables vir­tu­ally any inter­ested party to exam­ine what’s sent to the client and to dis­cern your test­ing strat­egy.  With a server-side approach, such as Adobe Target’s, the pay­load to the client is only the con­tent needed for that user, on that page view.  There’s no oppor­tu­nity for exter­nal dis­cov­ery of your brand’s test­ing plans and strat­egy, and, because the pay­loads are small, the impact on page load times is sig­nif­i­cantly less.

There are many rea­sons to man­date server-side archi­tec­ture within your test­ing and opti­miza­tion solu­tions. It makes sense, plain and sim­ple. The ben­e­fits are clear: seam­less, rel­e­vant expe­ri­ences for con­sumers, gov­erned by secure, flex­i­ble, test­ing and opti­miza­tion pro­grams for our cus­tomers.  Although secu­rity con­cerns may have made this a timely topic of dis­cus­sion, the under­ly­ing ratio­nale has always been clear.