Testing Bud for Comparison and Benchmark

This guide explains submitting a set of transactions to Bud to obtain enrichment results. Bud’s clients are often curious to see what category or merchant are identified for a dataset and compare those to the methods currently in use.

NB: When done effectively, the services built to benchmark a volume of transactions can be reused in production to ingest first party data.

To test Bud for comparison and Benchmark:

1. Contact us to get the process started. You will need to provide the client_id for your project in the Bud Console. We will configure your instance to support your analysis. NB: by default, the Bud Console will not support this benchmarking process, so you need to contact Bud first.
2. Create a service to hit the relevant API endpoints - customers, transactions, and (if applicable) accounts
3. Prepare your data to ensure it meets the requirements with categorization model, required fields, data formats and full transaction descriptions
4. Setup the service to bundle your data to submit into Bud FPI endpoints formats. To get started, these postman collections provide the example format you will need. Using postman, insert your data into these formats, and hit each endpoint to get your transaction results.
5. Schedule the service to stream API calls based on realistic volume (e.g. 10,000 transaction records per hour). This can be done through scheduling tools (e.g. cron) or calls can be submitted manually (e.g. Postman).
   • NB: If at any point you receive an HTTP response with the status code “429 Too Many Requests”, this means you’ve reached the maximum number of requests permitted for testing in Bud’s sandbox environment. In this situation, if you’d like to continue with your benchmarking exercise please get in touch with a member of our sales team, and we’ll be happy to discuss your needs further.
6. Capture the enrichment results that are returned from Bud: L1 category, L2 category, recurring transactions, merchant details, and processor details can be returned in the synchronous API response. Recurring transaction, income and product tags are added asynchronously so use the Get Ingestion Task Status and Get Transaction endpoints to obtain those

Caveats:

• Customer and Transaction ingestion calls need to be made independently and in sequence. The customer record must exist before transactions are loaded.
• Transaction APIs are limited to 1,000 transaction records per request so do not make bundles larger than 1,000.
  Standard Sandbox access blocks the relevant endpoints, so you need to let Bud know when you plan to run this.
• To see recurring transactions, you must submit a minimum 6 months of data for a user and create related Account records.