Publishing

Table of Content

Table of Content

Table of Content

Improving Results

Some options if you want to get even more out of publishing with Specify

Browser Caching

If you are calling specify.serve from the client side of your application you can enable browser caching (cacheMostRecentAddress) when initialising specify to greatly improve the percentage of users that see ads.

Without any caching enabled it's likely you will only be serving ads if a user has an active wallet connection, something that can very easily be interrupted with wallets locking or sessions timing out.

Important to note that this feature should not be enabled if you are calling specify from the server side - since we have no local browser storage to utilize (although it also will not break anything).

How it works

With the caching feature enabled we generate a unique random Id on the first serve request we receive where a valid wallet address is found. The next time that serve is called, even if you don't have a wallet address available for a user we can retreive the previously used address from the cache.

Whenever a user connects a new wallet on the same browser we'll overwrite the cache to contain only their most recent connected address.

We do not use third party cookies here at Specify as we believe it goes too far into invading user's privacy (and we ultimately do not need to with our tech). That decision extends to the contentious unregulated fingerprinting so our caching solution uses purely randomly assigned uuids to identify users, so if a user completely clears their browser's local storage we cannot work out who they were before.

You can of course implement your own caching solution if you want to be more aggressive or take an alternative approach and then simply pass addresses directly to our sdk.

Multiple wallets

Most publishers only allow users to connect one wallet at a time and usually there is no history. If, however, your platform does have some knowledge of multiple wallets for one given user then these can be passed as an array to our serve function.

This has a couple of large benefits:

  • More data to find the best ad for - the more active wallets we have for a user the better picture we get of what kind of protocols they like to use, meaning more accurate personalized ad serving is possible

  • More chance to catch a conversion - Since we can track new conversion activity across all those wallets, if they try out an advertised product on a test wallet first then there's more chance of us catching the transaction and sharing the revenue with you

©

2025

The Internet Community Company. All rights reserved.

©

2025

The Internet Community Company. All rights reserved.

©

2025

The Internet Community Company. All rights reserved.