Quick Tutorial

Our 3-minute Guide to Help You Use WISLR Like a Pro

We hope you’re as excited as we are to get those URLs over to WISLR’s algorithm. If it’s your first time using WISLR, this quick start guide will help you process your files and read the matching results.

Uploading Your Files

Here’s a few things to know regarding file management when using WISLR:

• Uploaded files should only be Comma Separated Value (CSV) files

• Individual file size cannot exceed 50MB

For the CSV file content, accepted CSV Headers are:

• URL

• SKU

• Dimension

URL is a required header, where all URL values should be listed. WISLR will work super fine with just URL data, but you can give it more if you have it.

SKU and Dimension are optional headers. If you include these values, the algorithm will apply them as meta data for the row they are added to. For example, these values will be associated together:

URL	SKU	Dimension
https://www.wislr.com/vacation-time	VACAY1	Sunny Days are in your Future

How to Use 'SKU' and 'Dimension' fields

The SKU field is built for any product specific ids you would export from your Ecommerce CMS. It's a way you can match URLs if you have SKU level data for products.

The Dimension field is built to accept any contextual and semantic text strings associated with a URL. Examples are:

• Title of the page

• Meta description

• H1 tag

The Dimension column only needs one of these values. We recommend choose the data point that is the most descriptive for the URL.

There is a limit of 2,048 characters for all ‘SKU’ and ‘Dimension’ cells in your CSV. The algorithm will truncate any strings that exceed this limit down to the threshold. ‘URL’ data has no limit on character length.

Here’s a File Upload Template to get you started. Send us a chat if you need help. Happy URL matching!

Reading the Returned WISLR Match File

When the algorithm has finished analyzing the URL datasets it will return a CSV file you can download. This file will include:

• All unique Origin URLs uploaded

• The (1) best Destination URL match

It is possible for some Destination URLs to not get mapped to an Origin URL, if a Destination URL is score lower than other URLs for the best match.

The final match file will have these headers:

• url

• best_match_id

• best_match_url

• score_301

• sku_match

• redirect_loop

• multiple_matches

Here’s a description of each field:

URL - the unique Origin URL string

Best_Match_ID - the unique system identifier for a Destination URL

Best_Match_URL - the unique Destination URL string

Score_301 - a value from 0 to 1, calculating the strength of the match. A score of (1) indicates the Origin and Destination URL are an exact match to one another, value for value. A score of (0) indicates that the match strength is very low quality. A value, such as 0.80, would indicate that the URL taxonomy between the Origin and Destination is a very strong pair. A low value, such as 0.20, does not indicate a poor match necessarily. It indicates that the URL taxonomy between the Origin and Destination is very different and this pairing was returned as the best result from the datasets provided.

SKU_Match - a binary value (True / False) that indicates if the SKU value was used to make the URL pairing

Redirect_Loop - a binary value (True / False) that indicates if implementing the Origin and Destination would create a redirect loop (pointing a URL with one value to another URL of the same value). False is the value you want to avoid Redirect loops.

Multiple_Matches - a binary value (True / False). An experimental field at the moment. It will indicate if multiple matches are returned for an Origin URL and the Destination URL. It surfaces matches that have the same ‘Score_301’ value from the analyzed datasets.