Architecture and Implementation Planning
Start with the decision flow, not the tool. A Target architecture plan answers: which client library (at.js 2.x vs Adobe Experience Platform Web SDK) and why; where the decision happens (on-device vs edge vs server-side via the Delivery API); how the visitor profile is keyed (first-party cookie, ECID, or a customer ID); and how experiences render without flicker (server-side rendering, pre-hiding snippets, or hybrid).
Know the moving parts: the edge network and decisioning service, the mbox/scope model, the visitor profile store, the offers library, the audiences/activities data model, and the reporting pipeline (Analytics for A4T, Target reporting otherwise). Understand the at.js 2.x single-page-app model - targetPageParams, getOffers/applyOffers, and the triggerView concept - versus Web SDK sendEvent with decisionScopes and renderDecisions.
Traps: confusing "server-side" (Target decisions made by your server via the Delivery API) with "on-device decisioning" (rules downloaded and evaluated in the browser/SDK). Also watch for questions implying Target stores raw PII in the profile - it should not; only approved attributes. Another classic trap: assuming activities work identically across at.js and Web SDK without checking supported features (e.g., some response-token and mbox behaviors differ).
Rule of thumb: if the page can render the experience before the network returns a decision, prefer server-side rendering; if the experience must be personalized per interaction in an SPA, use getOffers/applyOffers or Web SDK with explicit render decisions.
Worked example: a retailer on an SPA wants no flicker and per-view personalization. Plan: Web SDK, request decisions per view scope, render decisions client-side, and pre-hide only the containers that will be modified.