Address review feedback: improve clarity and add examples

apis/frontend/implementation-guide-session-api/spa-basics-tracking-events.md

@@ -2,7 +2,7 @@
 
 Instead of using [HTML tagging or tagging providers](../../../implementing-nosto/implement-on-your-website/manual-implementation/README.md), you will implement the same pattern for event tracking on all page types. Nosto needs to know what is happening during a user's session, mainly page views (like PDPs or PLPs), "add to cart" events and conversions.
 
-Regardless if an event was influenced by a Nosto personalization module (product recommendation/bundle or on-site content like a personalized banner) or not, **the fundamental call you make is always the same and varies on the page type**. When a shopper visits the homepage, you will call `viewFrontPage()`, when a search was made for "black shoes" you will call `.viewSearch("black shoes")` and so on. **All page types are listed with examples below**.
+Regardless if an event was influenced by a Nosto personalization module (product recommendation/bundle or on-site content like a personalized banner) or not, **the fundamental call you make is always the same and varies based on the page type**. When a shopper visits the homepage, you will call `viewFrontPage()`, when a search was made for "black shoes" you will call `.viewSearch("black shoes")` and so on. **All page types are listed with examples below**.
 
 ## Upon viewing the homepage
 

implementing-nosto/implement-on-your-website/advanced-implementation/adding-support-for-customer-group-pricing.md

@@ -4,10 +4,10 @@ In this article, you will learn how to implement multi-variants in Nosto. When t
 
 ## Edge cases
 
-If either of the following cases applies to you, we recommend either an API implementation or fetching the prices via an frontend API (instead of sending the price variations to Nosto). Please [reach out to our team](mailto:onboarding@nosto.com) or your Nosto onboarding manager for additional consultation.
+If either of the following cases applies to you, we recommend either an API implementation or fetching the prices via a frontend API (instead of sending the price variations to Nosto). Please [reach out to our team](mailto:onboarding@nosto.com) or your Nosto onboarding manager for additional consultation.
 
 * You can only change the pricing and the availabilities using this feature.
-* You cannot use SKUs with this feature at the time of writing.
+* You cannot use SKUs with this feature.
 * You cannot use Nosto multi currency with this feature.
 
 ## Ideal use cases

implementing-nosto/implement-psn/README.md

@@ -12,20 +12,20 @@ If you only have a complex product card but are using a Shopify theme, you can c
 - [ ] Nosto script in the frontend (Nosto Debug Toolbar is loading)
 - [ ] Knowledge of running a SPA or classic web application
 - [ ] General understanding of [how Nosto works](../../getting-started/README.md) and [what components make a stable Nosto implementation](../../getting-started/building-your-implementation-plan.md#components-of-a-stable-nosto-implementation.md)
-- [ ] One or multiple Nosto modules enabled in your account:
+- [ ] One or both of the following Nosto modules enabled in your account:
   - [ ] OCP: Onsite Content Personalization (like banners or text)
   - [ ] RECs/Dynamic Bundles: Product Recommendations (like "You might be interested in" or "Complete the look")
 
 
 ## Good to know before you start
 
 1. Every Nosto account comes with a set of default product recommendation campaigns and "placements" (empty `<div/>` elements). 
-   - You can see the mapping of campaigns and placements in the Nosto backend: Product Experience Cloud -> Recommendations.
+   - You can see the mapping of campaigns and placements in the Nosto Admin UI: Product Experience Cloud -> Recommendations.
    - These are sorted into the different page types like homepage (e.g. `#nosto-frontpage-1`), PLP, PDP, SERP, 404 page as well as general layout areas like the mini-cart drawer or search overlay/autocomplete.
-2. Your client will tell you which placements to put where inside your templates (or has already defined those within a design file).
+2. Your client will guide you on setting up placements in your store templates (or has already defined those within a design file).
   - Nosto campaigns need to be injected into the placements - automatically or manually, depending on your tech stack and implementation method.
   - Nosto offers you several helper methods to inject campaign into the DOM, you'll find details at the end of this page.
-3. Templates for RECs campaigns can be hosted and maintained in Nosto or built within your own code base (API approach, recommended for headless and SPAs).
+3. Templates for RECs campaigns can be hosted and maintained in Nosto or built within your own code base (API approach, recommended for headless and SPAs when using a custom code setup).
 4. Depending on your implementation method and tech stack, different options to attribute clicks from Nosto campaigns are available (it might need a few lines of custom code, you'll find details below per implementation method).
    - *Please note:* If you have the Nosto preview enabled, attribution/references will not show in the Nosto debug toolbar.
 5. OCP and RECs campaigns are always associated with exactly one placement.
@@ -36,7 +36,7 @@ If you only have a complex product card but are using a Shopify theme, you can c
 ## How it works
 
 1. After the Nosto script is loaded on a page, you can send a request to Nosto and will receive the campaigns for this specific page.
-2. Your request to Nosto needs to include certain data like the current page type, what's on the page (e.g. product data, the current category or search term), what's in the cart, if the customer is logged in and what placements are on the page.
+2. Your request to Nosto needs to include certain data like the current page type, what's on the page (e.g. product data, the current category or search term), what's in the cart, customer details if the customer is logged in and what placements are on the page.
    - You'll see [this `ev1` request](https://nosto.github.io/nosto-js/interfaces/client.EventRequestMessageV1.html) in your network tab and will monitor it extensively while implementing Nosto.
 3. The [Nosto response](https://nosto.github.io/nosto-js/interfaces/client.EventResponseMessage.html) includes mostly the [recommendation campaigns](https://nosto.github.io/nosto-js/interfaces/client.EventResponseMessage.html#recommendations) but also meta data like the [number of pages visited](https://nosto.github.io/nosto-js/interfaces/client.EventResponseMessage.html#pv) in the current session, a session ID, a customer ID and more.
    - OCP campaigns are always returned as raw [HTML](https://nosto.github.io/nosto-js/interfaces/client.AttributedCampaignResult.html).
@@ -92,7 +92,7 @@ This method is the fastest and works best for conventional builds where the temp
 In case you want more control about the campaign loading, you can disable autoloading and request the campaigns yourself. This approach is also suitable if you only want to request the product data in JSON per campaign and build the templates yourself.
 This approach is **not suitable for SPAs or headless frontends**, please see `Session API: defaultSession()` below.
 
-- The campaigns can return `HTML` (default, for Nosto-hosted templates) or `JSON`, depending on how you [build the request](https://nosto.github.io/nosto-js/interfaces/client.API.html#createrecommendationrequest).
+- The campaigns can return `HTML` (default, for templates hosted at Nosto) or `JSON`, depending on how you [build the request](https://nosto.github.io/nosto-js/interfaces/client.API.html#createrecommendationrequest).
 - By default, the request does not know anything about the current page, placements on the current page, logged in customer, cart content etc. and you have two options of passing that data:
   - Including the HTML tagging with `{includeTagging: true}`
   - Setting the data manually via JS, e.g. `setPageType("product").setProducts([product_id: "4"])`
@@ -111,7 +111,15 @@ You can also find a [video for the Session API](https://partners.nostoacademy.co
 
 - The campaigns return `JSON` by default, but in comparison to the JS API, you incorporate requesting campaigns with your page tagging/tracking via `defaultSession()` ([reference](https://nosto.github.io/nosto-js/interfaces/client.API.html#defaultsession)).
     - *Page tagging* refers to the JS API ([taggingProvider](https://nosto.github.io/nosto-js/interfaces/client.API.html#settaggingprovider)) and uses HTML and **MUST NOT** be mixed with the Session API.
-    - *Page tracking* is similar to the page tagging but uses JavaScript calls to let Nosto know what is on the current page.
+    - *Page tracking* is similar to the page tagging but uses JavaScript calls to let Nosto know what is on the current page. For example:
+    ```javascript
+    nostojs(api => {
+      api.defaultSession()
+        .viewProduct("product-123")
+        .setPlacements(api.placements.getPlacements())
+        .load()
+    });
+    ```
 - The page tracking sends the same [`ev1` request](https://nosto.github.io/nosto-js/interfaces/client.EventRequestMessageV1.html) which responds with the same campaign data and the same principles as the JS API.
 - Since requesting campaigns is tied to the `defaultSession()` for page tracking, you can run a very similar code block on the different page types ([examples here](../../apis/frontend/implementation-guide-session-api/spa-basics-tracking-events.md) and in the [API reference](https://nosto.github.io/nosto-js/interfaces/client.Session.html)).
   - The methods like `viewFrontPage()` or `viewProduct("4")` are the main indicator that campaigns will be returned.
@@ -184,7 +192,7 @@ mutation {
 
 Typical use case, options and adjustment depending on your implementation method:
 
-* A shopper is on a PDP (e.g. product ID 42), sees a Nosto product recommendation and clicks on a shown product (ID 200). You don't explicitly react to the click, you instead make sure the click listener for parameterless attribution is firing.
+* A shopper is on a PDP (e.g. product ID 42), sees a Nosto product recommendation and clicks on a shown product (ID 200). You don't explicitly react to the click, you instead make sure the click listener for parameterless attribution is firing. See the [parameterless attribution documentation](../implement-on-your-website/advanced-implementation/parameterless-attribution.md) for more details.
   * If you're using Nosto-hosted templates with autoloading, you don't need to do anything. Parameterless attribution is enabled and set up by default.
   * If you're manually requesting Nosto-hosted HTML templates via the JS API, you have two options:
     * Let Nosto inject the campaigns into the DOM via `injectCampaigns()`, this is recommended, attribution is set up automatically.