You definitely want to use Merchandising eVars for the additional items you want to track. Those can actually be added right into the product notation.
The format being:
[category (optional)];[product name];[quantity (optional)];[Price (optional)],[events (optional)];[merchandising eVars (optional)]
According to Adobe documentation (https://experienceleague.adobe.com/docs/analytics/implementation/vars/page-vars/products.html?lang=e...) category is not recommended for "product category", likely cause most products would fall under multiple categories, or can move around, etc) but I actually like to use this to help give contextual information to the item (but I am also using s.products for more than just my shopping cart so I can leverage the merchandising eVar and linked events functionality that is only available with s.products)
As you can see, Product Name is the only truly required field, the rest can be passed as empty values...or truncated after the last item populated:
// Include only product and category. Common on individual product pages
s.products = ";Example product";
// Include only product name
s.products = ";Example product";
// One product has a category, the other does not. Note the comma and adjacent semicolon to omit category
s.products = ";Example product 1,;Example product 2";
// A visitor purchases a single product; record quantity and price
s.events = "purchase";
s.products = ";Example product;1;6.99";
// A visitor purchases multiple products with different quantities
s.events = "purchase";
s.products = ";Example product 1;9;26.91,Example category;Example product 2;4;9.96";
// Attribute currency event1 only to product 2 and not product 1
s.events = "event1";
s.products = ";Example product 1;1;1.99,Example category 2;Example product 2;1;2.69;event1=1.29";
// Use multiple numeric events in the product string
s.events = "event1,event2";
s.products = ";Example product;1;4.20;event1=2.3|event2=5";
// Use merchandising eVars without any events. Note the adjacent semicolons to skip events
s.products = ";Example product;1;6.69;;eVar1=Merchandising value";
// Use merchandising eVars without category, quantity, price, or events
s.products = ";Example product;;;;eVar1=Merchandising value";
// Multiple products using multiple different events and multiple different merchandising eVars
s.events = "event1,event2,event3,event4,purchase";
s.products = ";Example product 1;3;12.60;event1=1.4|event2=9;eVar1=Merchandising value|eVar2=Another merchandising value,Example category 2;Example product 2;1;59.99;event3=6.99|event4=1;eVar3=Merchandising value 3|eVar4=Example value four";
That said... as much as I hate wasting eVars with tracking the same info, I find that creating an eVar to hold the same value as Product Name helps in trying to create segments (if that is something you will be doing)... Creating a segment for "product equals x" or "product contains x" will return all products that were part of the same call, but if you use the eVar in your segment, it will return only the products you expect.
I don't know exactly your needs or setup, but it sounds like most of the values you are collecting would be eVars, but maybe, when it comes to tax or shipping costs... if you want those as actual numbers that you can do calculations on, you might want to consider setting up a currency based event for each of them... then pass the value as:
s.products = (optional cat);productx;(quantity);(price);(other events here);eVarx=black|eVary=large.....
s.events = "eventx=2.60,eventy=9.99"
where:
eVarx is color
eVarY is size
eventx is a currency based event for "tax"
eventy is a currency based event for "shipping"
etc
Unless you are trying to collect the shipping and tax for each individual item, it makes more sense to capture the entire order's tax and shipping outside of products.
Then you might have 5 products, each with size, color, whatever associated to the product notation with individual prices and quantities; but the entire order would have the tax and shipping.... (or you could apply tax and shipping to each individual item if you really feel that is needed....)
Right now, seeing as how you are starting... play with options in a testing suite... try creating reports from your test data.. create segments, apply math to the your values, see what works, what doesn't work... keep tweaking it until you have something that works for you and your business needs.
Getting ideas at a high level like this can help point you in the right direction, but I always feel that a little hands on testing is the best way to fully conceptualize the solution. And don't be afraid to push back a little on the timelines.... do they want it done, or done right? The second one takes longer... but is worth it in the end.
