Showing posts with label Endeca Design and Best Practices. Show all posts
Showing posts with label Endeca Design and Best Practices. Show all posts

Endeca Baseline/partial update failed : How to run Endeca baseline/partial update even if one of the Dgraph instance is down?

There isn't any existing OOTB functionality that would allow you to skip a Dgraph that is down and continue to carry out running baseline or partial updates. This requires customization.

(1) You can either manually modify your Appconfig.xml to remove the down Dgraph or perhaps create a custom script that either does this for you or otherwise error traps the Dgraph that is down.


(2) You can check whether each Dgraph is active or not by using the Dgraph.isActive() method and if you get any exception then the EAC agent is dead.  You then need to skip updating that agent and send a high priority email.

Keyword Redirects - Endeca Best Practices

Use keyword redirects to drive users who are searching on common self-service terms to the appropriate pages, rather than searching the data set for related entries.

Ex: https://www.shopmyexchange.com

It Redirect a user who searches on shipping to the Shipping and Delivery page instead of returning catalog results with that term in the title

Auto-Correction / Spell Correction - Endeca Best Practices

1) Applications should present feedback and clarification to users about spelling corrections

 

2) The MDEX Engine flag --spell-glom should be used to enable cross-field spell correction. This will enlarge the dynamic spelling dictionary created by the engine by including entries across different properties or dimensions.

Endeca - Cascading Search

Definition:
An Endeca application can be configured to search a variety of record properties or search interfaces in order of decreasing importance. This “cascading search” provides the best possible experience to users by presenting highly relevant results when they are available, and, if not, returning the potentially less relevant results that would otherwise have remained hidden.

For example, many product catalogs contain at least two fields that describe an item: a title field with, e.g., brown shoes and a description field of, e.g., these formal brown shoes complement navy socks. 

Users searching for navy socks generally would not find this result relevant, but it’s probably better than returning nothing if there are no other matches for navy socks.

How to implement it? 
- Create second search interface that contains all of the searchable fields from the original interface, plus the description field(s).
- Add application logic where search across first interface and if you get fewer than N results then search across second search interface

N can be equal to zero, or a small number like 2 or 5 or 10.

Best Practice:
1) If the data set has descriptions that contain marketing text or other copy that does not directly describe the record in question, exclude them from search if at all possible.

2) If excluding semi-relevant descriptions is not feasible or desired, implement cascading search, so that these properties are searched only when fewer than N results are returned.

3) Cascading search applications should use the MatchAll match mode on the primary interface and MatchAllPartial on the secondary (long description) interface.

Endeca Stop Words - Endeca Best Practices


Regularly review the current stop word list and reconcile it against the most popular searches. 

Remove as stop words any terms that are searched on regularly, or set those terms as keyword redirects to useful overview pages.

A list of potentially useful stop words: a, an, the, how, do, I, me, and, no or, when, where, why, are, is, you, have, it, from, over, under

How to gather Server Statistics During the Endeca Baseline? - Endeca Baseline

Run below command before you kick of baseline update.
 top -b -d 60 -n 20 > ServerStats.out
Above command gathers 'top' statistics every 60 seconds for the next 20 mins. 

ATG-Endeca Oracle Commerce site performance degrades and toll on application tier memory - Best Practices

Problem Statement:

ATG-Endeca Commerce site performance degrades and toll on application tier memory

Solution:

If aggregation is defined in the Endeca with below configuration(allbins=2) and there are so many sub records are rolled up per product. 
/atg/endeca/assembler/cartridge/handler/config/ResultsListConfig
subRecordsPerAggregateRecord=TWO 

You can fix it as below:
1) Configure records Per Aggregate Record set to 1
 atg/endeca/assembler/cartridge/handler/config/ResultsListConfig
   # For aggregate records, sets the number of sub records that should be included in the results
 subRecordsPerAggregateRecord=ONE 

Endeca Relevance Ranking - Best practice

Best Practice: For applications dealing with Retail catalog data, the preferred order of modules is:
1. NTerms
2. MaxField
3. Glom
4. Exact
5. Static


Explanation: 
NTerms, the first module, ensures that in a multi-word search, the more words that match in the record, the higher the record is scored.
MaxField puts cross-field matches (see Allowing Cross-Field Matches) as high in priority as possible, to the point where they could tie with non-cross-field matches.
Glom, decomposes cross-field matches, effectively breaking any ties resulting from MaxField. Together, MaxField and Glom provide appropriate cross-field match ordering, depending upon what matched.
Exact module means that an exact match in a highly-ranked member of the search interface is placed higher than a partial or cross-field match.
Optionally, the Static module can be used to sort remaining ties by criteria such as Price or InstockWeb.


Example: Below Screenshot shows on how to configure Rel.Ranking Modules using Endeca Pipeline



Best Practice: For applications dealing with Document Repository Data, the preferred order of modules is:
1. NTerms
2. MaxField
3. Glom
4. Phrase

5. Static

Explanation:
NTerms, the first module, ensures that in a multi-word search, the more words that match in the record, the higher the record is scored.
MaxField puts cross-field matches (see Allowing Cross-Field Matches) as high in priority as possible, to the point where they could tie with non-cross-field matches.
Glom, decomposes cross-field matches, effectively breaking any ties resulting from MaxField. Together, MaxField and Glom provide appropriate cross-field match ordering, depending upon what matched.

Phrase module ensures that results containing the user's query as an exact phrase are given a higher priority than matches containing the user's search terms sprinkled throughout the text.
Optionally, the Static module can be used to sort remaining ties by criteria such as Price or SalesRank.