Direct links to shop products for marketing, SEO and more (permalink, deep link)

Software improvement 4-In delivery
1

What is the need/problem?

DIrect links to products in the shops are very valuable for marketing reasons and searche engine optimization (SEO). One example would be the advertisement of cetain products in a newsletter or in social media, where the shopper is then directed to the product directly.

Currently there is no option to use direct links because we are using modals instead of a product detail page (PDP).

Who does it impact?

Shoppers are impacted as they cannot be directed to products directly, but they have to find the product amongst all the others in the shop.

Shop managers and hub managers are impacted as they cannot do efficient advertisement of certain products, or if they do, they will lose many shoppers along the customer journey.

Shop managers, hub managers and OFN in general are impacted as search engines cannot find the offered products, or if they do, they will be rated low due to the missing direct links and backlinks.

What is the current impact of the problem?

As a result of the above-mentioned, shoppers suffer from long and inefficient customer journeys and the shopping experience is negatively affected.
Shop managers and hub managers suffer from missing advertisement options and consequently reduced turnover.
The overall visibility of the OFN and its products in search engine results is being reduced.

What is the benefit of focusing on this?

Efficient advertisement capaigns on all channels are enabled.
Producers can direct shoppers directly to certain products.
Visibility in search ingines will be improved.

Potential solutions that will solve the problem?

Solution 1

Create direct links to modals in the shop

  • straight forward if there is only one open order cycle
  • Example: product with permalink “apples”: https://staging.openfoodfrance.org/example-shop/shop/apples
  • Benefit: quick win regarding direct marketing and SEO
  • Downside: inconvinient user experience with high barriers towards conversion (will not be part of the main user flow)

To be clarified:

  • How to handle this, if there are multiple open order cycles, because the product may be in one order cycle and not in the other?
  • How to handle this, if there are no open order cycles?

Luis:

Could be shown over the shop page even if there are multiple or no order cycles. Example:
http://0.0.0.0:3000/fredo-s-farm-hub/shop/garlic
Initially we can even make it so simple it will not cross check the hub name in the URL with the product name in the URL. It will just display whatever product in whatever shop (users need to build the URL correctly).
In a second step, we can then improve it to validate if the product has ever been sold (or can be sold) by the hub.
Even if we assume the product in the URL matches the hub in the URL, if the user is coming from outside, we may get her looking for the product in open OCs and realizing the product is not for sale right now. As another extra step we can improve the PDP to list all OCs where product is sold or add a message “product is not currently for sale”.

Maikel:

The issue says: “link directly to the product detail within the shop”. I think that means the shop product listing tab. But that doesn’t define the order cycle. It’s also not easy to use the URL fragment because that’s already used for the tabs (and login modal).
I like your idea of putting it in the URL request part. But I can already see problems when people have a full cart in one order cycle and then click on a link to a product in another order cycle. I think this needs more inception.
Users needing to craft the URL and people seeing a product on a shop front that is not in the product list will be very confusing otherwise.

Rachel:

I’m not sure I’m following what it means to “build on top of the shop URL”. Does it means shop URL + permalink of the product = product URL?
I think I agree with Maikel. I wonder if this isn’t the way to design a full product page, instead of a modal… Modal don’t display way in mobile anyway. Maybe something for the next round of mobile work?

Solution 2

Create direct links to modals in the ‘about’ page

  • load the about page of the enterprise and open the product modal on top of it
  • load the product description independently of whether it’s on sale in a given order cycle or not
  • Example: https://staging.openfoodfrance.org/ugandan-spices/apples
    that would load https://staging.openfoodfrance.org/ugandan-spices/about with the product modal for apples
  • Benefit: very important for SEO to have a stable page, not a page that appears and disappears in different versions (the shop page with different products) all the time according to order cycles
  • Benefit: creates space for having a normal PDP independent of order cycles (see solution 3 below)
  • Downside: inconvinient user experience with high barriers towards conversion
  • Alternative: load the modal over the shop page independently of whether it’s on sale in a given order cycle or not (see solution 1)

To be clarified:

  • Where would we pick the product from?
    Proposal: Use any open order cycles OR otherwise look for products in the list of all the products in all enterprises that this enterprise can sell products from.

  • What Modals will be active and what Modals should be blank?
    See Solution 3 ‘What PDPs will be active and what PDPs should be blank?’

  • Which order cycle should be used (when showing the modal over the shop page) if there are multiple open order cycles?

Luis:

I dont think we should build a PDP outside the modal, I think that will require a LOT of work (design dev etc). I think we should get the URL/modal thing working. I agree landing on a modal with a product that is not in the listing below the modal is weird, I think we should find alternatives.
My proposal is to open the existing product modal over the shop’s About page where the user can close the modal and click Shop.
In a second, also easy step, we can add the list of OCs to the product modal where the product is currently for sale that will enable the user to jump directly to the OC where the product is.
I think this simple feature would improve the very poor situation a lot.

Danielle:

In terms of experience, I don’t actually think what you’re describing @luisramos0 is the best solution. If the goal is to have the shopper buy, why would we take them to the modal if they then can’t buy the product? The extra clicks to then get the shopper onto the shop list, to see the product, and then to purchase it is far too big a barrier to conversion.

Yuko:

As much as I would LOVE to have PDPs, I don’t think hacking the modal is the right way to get us there.
As a user I would get to the PDP and not be able to buy, nor see the price, nor see the availability of the product – and then be forced to navigate to another location and search for the product in a list :cry: + :angry:

Luis:

The modal with the list of OCs will make the user land on a page with a link to the right shop, I dont think it would be too bad.
We can add the product variants and price next to the OC but I think that would be better after migrating the modal to a page and proper design.
For now I’d suggest the modal with the links to the OCs, just that.
I vote to get this done now with URL and a PDP on the existing modal because it’s easy and will get us very good value.
Not doing it now it means closing this issue, going back to discourse for Inception and design: the year will be 2021 at least.

You are damn right, @luisramos0! :joy:

Solution 3

Use product detail pages (PDP)

  • PDPs are a standard in the e-commerce industry
  • PDP shows the product details, a list of the order cycles it’s in, whether it is currently on sale or not, and a link to the shop
  • requires a lot of work incl. design
  • modals are not displayed on mobile devices so PDPs would be good

To be clarified:

  • What PDPs will be active and what PDPs should be blank?

    • Example: A hub with access to 6 farmers with 10 products each: 60 products. The hub only sells 40 of these products and has overrides for 20 of these 40 products, the hub never sells the other 20 products.
      What products will have a PDP?
      1. all the 60 products
      2. just the 40 products that have been in some order cycle before
      3. just the (for example) 31 products that are in an open order cycle right now
        (this has the big disadvantage of making PDPs appear and disappear as the OCs open and close)
      4. just the 20 overridden products
    • Opinions:
      Lynne: All the 60 products, but shoppers can only access them through direct links or through an open order cycle. This is to avoid shoppers to see PDP of products they cannot buy, it is easy for hub managers to create and edit the direct link within the product/variant, it is good for SEO. The PDP could be hidden by the hub manager.

  • Should prices be shown on the PDP?

    • This is tricky because prices can be modified by order cycle, distributor or per-user vis tags
    • Opinions:
      Konrad: Yes, the price is one of the most important information about a product. Only order cycles that are currently open and the user is permitted to buy in should be shown. If there are different prices, it is only transparent to see this on the PDP.

Lynne:

Oh dear. I’m quite concerned about this falling out of scope. The two main things people want in shopfront are PDP and images on mobile. PDP is crucial for shopfront marketing on social media… and that is going to be a crucial part of shopper retention when things start to go back to normal.

Selection of a feature candidate

Danielle:

Doesn’t need to go through the full process so much as be agreed as a priority in the roadmap. We can bring this to the next product curation session.

T-shirt size of our selected feature candidate

1 - the URL to the product modal is not difficult to do - XS
2 - adding the list of OCs is a little effort that becomes bigger if you want to have the price - S+
3 - moving the exiting modal to an equivalent/simple page on it’s own is also not difficult in terms of dev (it just requires design) - M
4 - adding the classic “add to cart” button will be another design challenge (multi OC) and also a bit of a dev challenge to make it work properly - M+

Metrics to measure if need is satisfied after feature is implemented

  • Compare search engine results before and after implementation - rating should be improved.
  • Compare conversion rates regarding advertisement in newsletters and social media before and after implementation - conversion rate should be omproved.

Feature owners

t.b.d.

Epic/projet where you can follow implementation

t.b.d.

Additional info regarding inception

Danielle:

We can prioritise this to be done, separately to the mobile work.
So, I think this requires to be taken up a level - what is the problem we are trying to solve, and then we start talking about solutions. I think this will be prioritised by the global community, but the thinking about how it will work has not been done, and wasn’t included in the mobile shopping original scope (as per @kirstenalarsen’s slack response, we’d added it because it felt like a quick win but in hindsight it wasn’t actually that).

Yuko:

I think it’s worth at least scoping the need properly to understand what a more long term solution would look like (logic + dev) and I’m happy to bring preliminary designs (yes I have them - in this instance it’s the easier part!).

Connected wishlist and discovery discussions*

For information only (not required to be read):

  • Slack discussion: Rachel, 29. Jan. 2020 Hello! Does someone know how permalinks on products are used? Is there a way to build a URL pointing to a product description thanks to them?
  • Slack discussion: Danni, 10. Feb. 2020 Hey @devs would it be difficult to create direct links to product modals? Ultimately it would be awesome to have individual product pages, but in the interim can we just directly link to the modal?
2

To summarize all this on a very high level, I would say the first question to answer would be:

Go for the quick win using the modals or do it right with more inception, proper design and new product detail pages?

If the decision is to go for the quick win, there are only minor things to discuss and decide.

3 Likes
3

Dear all,

I would like to follow up on this topic and ask you all for your opinions. Would you prefer to have direct links to products which can be used for marketing in newsletters, social media etc. by

A) going for the quick win using modals (the current overlays with the product details) - short development time
or
B) doing it right with more inception, proper design and new seperate product detail pages for each product - long development time

Please reply to this post and let us know what you think! How urgent is this? How big is the benefit of product detail pages?

We have discussed this in the german instance and decided to vote for the quick win (A).
Reasons: We believe that the benefit from direct marketing of products in social media, newsletters, etc. is huge and a must have. Compared to this, the benefit of increased SEO performance of product detail pages comes at the cost of very long development time (including inception and design) and is rather small. We should definitely have product detail pages at some point, but we really need to make use of the marketing possibilities as soon as possible!

Thanks for sharing your thoughts! :slight_smile:

4

We (OFN-CAN) would go for A at this point. Our users are increasingly engaged in direct (mostly social media) marketing of their stores. I think they would like improved SEO performance of course - but I think there are short term wins with direct marketing, and as an instance we can assist users with this. Getting better marketing possibilities in the short term (and riding the second ‘wave’ of local food consumers due to covid) is a strong need now.

1 Like
5

I totally agree with konrad, I also think that the quick win is a better option and there would only be some minor things to be discussed decided or fixed. The right way, with a proper design and new product detail pages is also a great idea, however it requires way more resources, and when I am sayin resources I mean both time and money, probably even nerves. To be honest, after reading this article Why You Need Quora and Reddit for SEO and Marketing in 2021 | SEOblog.com I understood the real power of seo, and how we should actually do it.

6

Hi everyone,

I’m working on an inception of a small sized version of this issue. As we know from these discussions creating a workable solution in size S is difficult. However I think we agree that we can still create significant gains within this size.

I’d be interested in the feedback of folks here. I believe that this solution creates significant improvements, minimises the problems that have been identified, and can successfully be implemented in size S.
Would you be satisfied with the following solution?

https://www.openfoodnetwork.org/fundedfeatures2/

1 Like
7

Hi @lin_d_hop,

Thanks for working on this! The German instance would be satisfied! :smiley:

1 Like
8

Just wondering - I note that you mention that social media previews will not work well. So - what will happen? If I have a link to a product on my fb page — will it take the user to the shop where they can buy the product?

9

So - what will happen? If I have a link to a product on my FB page — will it take the user to the shop where they can buy the product?

@tschumilas
Yes, the links will befully functional, i.e. take users to where they should. By

social media previews for these links will not be pretty

is meant the implementation of “rich links” that you know from FB & Co, where
link previews provide more contextual information than plain URLs – by giving your link an image, title, description. These “OG Tags” allow any website to become a rich object in a social graph if provided with the necessary metadata.

10

Hi team,

I’m back, but this time as a hub user :slight_smile:

We are applying for a grant and I would like to include a line item for getting this feature funded in that application. Am I able to get more detail @Jana on what you mean by the above comment - maybe a rough mock up of what an ‘OG Tag’ will look like in FB. Thanks!

Chez (Australia)
cc @RonellaG

1 Like
11

Hi all, I have spent some time looking at this, below some early thoughts.

Product information
What is the information that would drive conversion?
What data can we display easily?
What data is important but can’t be displayed easily?

  • product name (easy)
  • image (easy)
  • product description (easy)
  • producer (easy)
  • enterprise shop (easy, is it useful?)
  • tags (easy, is it useful?)
  • variants (not so easy, requires cycle selection)
  • variant details (not so easy, requires cycle selection)
  • price (not so easy, requires cycle selection)

Could we pilot this with the easy data first and then add the not so easy?

Next, I’m listing the possible scenarios to assess which ones need to be considered.

  1. is the link active/working?
  2. is the product publicly available?
  3. are there multiple product variants? (maybe it doesn’t matter)
  4. is the product sold by other enterprises? (maybe it doesn’t matter)
  5. is the product available in any active order cycle?
  6. are there multiple open order cycles?
  7. is the person logged in?
  8. is the person shopping in another store?
  9. does the person have products from another store in their cart?
  10. is the person shopping in the store from the link?
  11. is the person shopping in the store from the link in a cycle that has the product?
  12. does the person have the product already in their cart?

Keen to get people’s inputs on both what data is critical, if the scenario questions are relevant and if I’m missing any scenario question.

Thanks!

1 Like
12

Heya @Mario
Here are some answers to your questions based on what came out of previous inceptions:

What is the information that would drive conversion?
Being able to add to a cart.
What data can we display easily?
Anything already in the product modal
What data is important but can’t be displayed easily?

  • product name (easy) → Already in modal
  • image (easy) → Already in modal
  • product description (easy) → Already in modal
  • producer (easy) → Already in modal
  • enterprise shop (easy, is it useful?) → Needed to add to cart
  • tags (easy, is it useful?) → Do you mean labels? Tags are for BE management
  • variants (not so easy, requires cycle selection) → It would be up to the user to ensure the modal description captured variant info. This can be selected to add to cart.
  • variant details (not so easy, requires cycle selection) → Same answer as above
  • price (not so easy, requires cycle selection) → Was decided out of scope, see on next click

Could we pilot this with the easy data first and then add the not so easy?
We did scope out that this feature is useless if you can’t add to a cart. The rest of the ‘not easy’ info is okay as you can find on the next click.

  1. is the link active/working? → more detail below
  2. is the product publicly available? → more detail below
  3. are there multiple product variants? (maybe it doesn’t matter) → Doesn’t matter, choose in cart
  4. is the product sold by other enterprises? (maybe it doesn’t matter) → the MVP is that this feature is built on the shop, so there won’t be an option to see the other OCs. I would say a good next phase would be to have an option to show everywhere the product is available.
  5. is the product available in any active order cycle? → Potentially yes
  6. are there multiple open order cycles? → Potentially yes
  7. is the person logged in? → the OCs available will be based on user auth
  8. is the person shopping in another store? → if so they will see the warning
  9. does the person have products from another store in their cart? → if so they will see the warning
  10. is the person shopping in the store from the link? → this should create no issues
  11. is the person shopping in the store from the link in a cycle that has the product? if not they will see the warning. Ideally if they have a cart already the OC is chosen for them, but this will push the scope
  12. does the person have the product already in their cart? → if so, based on the solution found it will come up showing how many are already in the cart when they ‘search’

Responding more deeply to 1 and 2 to try and navigate broken links I would suggest:

  • Any product that has been added to an enterprise OC in the past should have a link.
  • If the shop has no open OCs the modal should still display but with a short version of the OC closed message.
  • If the product is simply not in a currently open OC a different message would be ideal
  • If the product is sold out or has zero stock again another error message would be ideal
  • Perhaps the last two could have a single error ‘This product is currently sold out or unavailable’
  • In the case that the user has a cart for a product with the enterprise on an OC but the product isn’t available in this OC, yet is available in another (the trickiest edge case to my mind) the ideal would be to display a message ‘This product is currently sold out or unavailable for your current basket’… and maybe have the OC select option as well. But this feels like scope creep for an edgy edge case. Let’s ponder the minimum here.

Thanks for all these very helpful and curly questions @Mario. I do think that mostly the feature will work, but there are certainly lots of curly situations in which the UX will be confusing if they are not captured. I’m def in favour of finding the minimal solution that will work most of the time and

13

I’d just like to check something here, which may well be dismissed / irrelevant as scope creep, but with all the other things moving, rapid developments on DFC side, imminent look at Discovery endpoints etc is worth asking . .

TL:DR (below) to get to this point. I have three questions:

  1. in your comments about error messages @lin_d_hop - are we assuming that these are more ‘info’ messages i.e. the product modal still works and shows info about the product, but contains the information that it is sold out / unavailable?
  2. why are Product Modals getting created by ‘Shop’ - there is a ‘native’ url generation, we just don’t use it. If we used this, it’s just about bringing it to life and having it go somewhere, the data of a link for each product is already in there and can be used. If we did this, then we would NEED at least a list of Shops to be workable, I get that this is probably why other approach was proposed, to try and keep it simple . .
    image
    image1272×564 34.7 KB
  3. BUT with $$ for Discovery Endpoints and progress on DFC, we could consider developing OFN REST Offers endpoint and/or DFC Offers Connector. This would (perhaps) serve Shops and OC info, and could (maybe? not sure about tech) be used in this modal, as well as other external use cases (e.g. maybe Macdoch). Given Macdoch project, if we were going in this direction (not yet decided) it would make a lot of sense to prioritise DFC as solution to be developed should not be OFN-centred

. . . thinking process

  • Discovery endpoints -
    • This is not incepted yet but could lead to a priority use case in which we want to do product search from a separate site and then link into OFN to buy. What would we need this product on a separate site to show?
    • I think it would want to have the product, but then also show all the ‘Offers’ right? i.e. show which Shops (at minimum) and potentially later the OCs themselves?
    • I see that a shop generating these links might want them to be purely for their shop, but are we anticipating that the Shop is actually generating them? Or they are just being created by default somehow i.e. a link is being created with the Product itself, which means we can’t isolate it to just one shop without some more complex logic? Might actually be easier to just have one Product, one Link, one Modal, and have that modal show all ‘Offers’ i.e. Shops and/or OCs that it is available in
  • DFC Product Connector:
    • probably already contains all the easy information, and if it doesn’t then my understanding is that it can be added easily.
    • I know this goes to a ‘tech stack’ question, but could the modal use DFC Connectors ‘internally’? Then it might make sense to use some Discovery Endpoint money to develop the DFC Offers Connector? Would this create a piece that would then mean the architecture for those extended use cases would be in place?

My head is spinning, I wish we could all be in a room. I am going to brainstorm possible Discovery endpoints, so that we can then assess how many already have DFC ontology and where we would be ‘setting’ that. But totally open to the idea that we just build them as DFC Connectors if we’re at the point where they are immediately useful as such. If we did this, then this modal could maybe benefit from this.

14
  1. Yes info messages
  2. So that a shop can share a link on their FB page and not have the link direct the user to another shop. The point is promotion.
    I would say a producer linking to any available outlet would be a great feature. If there is additional funding from discovery to implement this we should.
  3. Looks like you are talking about full PDPs. Is there funding in discovery to explore this? As described at length through this thread, that is out of scope for this 3 day feature.