Welcome to the Cyara Knowledge Center

This article is intended for customers preparing to use Cyara Pulse for production/operational monitoring. 

Cyara Pulse is different from Cruncher or Velocity in the following ways:

• Test Cases: There are no tag usage restrictions in test cases run in a Pulse campaign. 
• Campaign: Pulse is the only campaign type that allows for recurring scheduling.
• Integrations: Pulse is the only service that supports canned integrations to Splunk, ServiceNow, and PagerDuty. 

Crawl: Planning

- Know one's Pulse port capacity and expected monitoring frequency. These are critical to setting up proper scheduling and avoiding port contention. See Pulse Schedules.

- Understand one's change management process. Stricter change control processes aid with the updating of test cases used for production monitoring and help avoid false negatives. 

- Start with breadth of monitoring and then move to depth of monitoring if one has enough port capacity. 

- Have documented baselines for the customer experience key performance indicators (e.g. time to connect, response time, etc.) for all test cases in advance. 

- One does not have to monitor every step. Plan for only the most important steps of the journey that need monitoring such as those steps involved with backend web services, database look-ups, etc. 

- Be aware of IVR and contact center metrics and how tests may impact reporting. 

Walk: Test Cases

- Consider a strategy to use blocks for easier change implementation and re-usability within or across test cases. 

- Use a common naming convention for folders and test cases. 

- Start with building broad test cases that span the entire list of entry points one's customers may use. These test cases should be 2-3 steps maximum (including Step 0). 

- Move to building deeper test cases that span only the most critical journeys. These test cases should be 4 steps or greater. 

- Again, one does not have to monitor every step. Plan for only the most important steps of the journey that need monitoring such as those steps involved with backend web services, database look-ups, etc. 

TIP #1: Use {*} or {Ignore} tags for those steps that do not need to be monitored. 

TIP #2: Use ANI/CLI spoofing to know which voice test calls are from Cyara so they can be removed from IVR containment reporting. 

TIP #3: If using any data-driving features, be sure to use a variable in the test case description field to be able to distinguish journeys under test. 

TIP #4: Use the {BargeIn} tag on the final step to ensure the test call ends in the IVR before being transferred to the contact center queue. 

Run: Campaigns

- Cyara recommends using the round-robin distribution profile. 

- Schedules must be used to prevent ports from being exceeded which causes campaigns to fail to run. 

TIP #1: Use a Microsoft Excel spreadsheet or Google Sheet to build a template to track all campaigns being used, run frequency, and total number of test cases. This will make adding and scheduling new campaigns much easier. See the sample attached. 

TIP #2: If one also has a Velocity subscription, add all test cases into a Velocity Campaign and run there first using only a single port before adding into the final Pulse Campaign. The Velocity Campaign will give one the total time needed to run all test cases with a single port. One may then easily calculate the total run time if two or more concurrent ports are used in the Pulse Campaign. 

Part 2: Cyara Pulse Dashboards