This article covers common questions about server-side implementations in Swrve.

What is a server-side implementation?

A server-side implementation is the use of Swrve without or in addition to the Swrve platform-specific SDKs. Typically this is done by using the Swrve Events API to send events and user properties in an automated way.

Some common use cases for a server-side implementation are:

• To send Swrve currency events when actions happen outside of the app.
• For additional in-app purchase and subscription revenue validation.
• To send other information about the user from outside of the app that you want to use in Swrve; for example, web usage details, other device data, or profile data of users.

What should I be aware of when planning a server-side integration?

Some examples of the service limits are:

• The average number of events sent per minute per user over any period of time should be 10 events or less. Events can be sent more frequently but the average should be 10 or lower.
• A/B tests and in-app campaigns should not be requested more than twice per minute.

You should adhere to the following guidelines when using server-side integrations:

• Where possible, send data using the Batch API call to reduce bandwidth requirements and send events in bulk.
• Never use non-client APIs in production, such as the Items API.
• Ensure that each user has a unique user ID. If the Swrve SDK is integrated into the app, by default it assigns a unique ID per install. If you do not have a Swrve SDK integration in the app, you need to manage this. If the ID of a user changes, Swrve treats this as a new user.
• Don’t use the Swrve name space when sending events (for example, Swrve.event_name) since these are reserved for automatic Swrve events within an app SDK implementation.

What are the limits of only using a server-side implementation?

If you do not have a Swrve SDK implementation within the app at all, you won’t be able to use the following features without development work on your side:

• In-app messages or embedded experiences
• Push notifications
• Tracking marketing activities
• Limited testing of QA Devices from the Settings menu

What if I have both a Swrve SDK and server-side integration?

Remember that Swrve tracks each user on a per install level with a unique user ID. If you want to send events or properties for a user, ensure you know their user ID and use this when making the API calls. Otherwise, a new user is created.

How can I make sure data sent from my server doesn’t impact my KPIs?

Set the user_initiated flag to false for any user attribute events. Custom events, purchase events and other event types impact the KPI charts regardless of the above flag.

How do I QA test my server-side implementation?

We recommend first sending data to a sandbox dashboard to make sure you are sending the data you expect.

For detailed information on how to send events and properties via the Events API, see the Swrve Events API guide. When sending events or properties, you need to specify the Swrve user ID. Each user within your app should be assigned a unique identifier.

We recommend testing the progress first by adding your device as a QA user and noting the Swrve user ID on the QA User Logging screen. Take note of your ‘Swrve ID’ ahead of time so you can add this ID easily.

You can then test the server-side implementation using the QA device ID, and inspect the QA User Logging screen to see the events and properties being sent in real time.

You can view all of the events and user properties for every user in the User DB downloads that are generated daily. We recommend you download the User DBs and check that the values have been set as expected. For more information, see Intro to user databases.