Download the PHP package zumba/amplitude-php without Composer

On this page you can find all versions of the php package zumba/amplitude-php. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package amplitude-php

Zumba amplitude-php

Build Status Coverage Status Scrutinizer

This is a moderately thin PHP API for Amplitude, powerful enough to do what you need without getting in the way. Designed to work well in 2 main scenarios:

Example

Getting Started & Troubleshooting

When you are initially getting your application set up, if you do not see your event show up in Amplitude, you may need to do a little troubleshooting. Normally your indication that "it worked" is when you see your event show up in your Amplitude app for the first time.

If you never see that first event show up, you can see what Amplitude's response is when the event is logged. This may help find and fix the problem (such as an invalid API key, PHP environment errors, connection problems, etc.)

Amplitude uses Psr\Logger for logging the communication with the Amplitude HTTP API. You can take advantage of this by setting a logger (using $amlitude->setLogger()) to help catch any problems.

Stand-alone Troubleshooting Script

Below is a stand-alone script, meant to be copied into a PHP file at the root of your application's document root. Just change the APIKEY and if needed, adjust the line that requires the autoload.php file for composer. Then visit the script's URL from a browser to see any messages logged.

Troubleshooting Tips

Logging Anonymous Users

Since this is a PHP SDK, there are a lot of options for tracking Anonymous users. Since this could be run in CLI mode or as a cron job, this SDK does not handle sessions for you.

Your application will need to figure out a way to track users across multiple page loads, chances are your app is already doing this with PHP sessions or something like it.

Once you have that unique identifier that allows an anonymous user to be tracked between page loads, set that as the deviceId. Do this for both logged in users and anonymous users, that way once a user is logged in their past events will be linked to the user.

User Properties

There is one main way to set user properties, and this will send the user properties with the next Amplitude event sent to Amplitude:

You would typically call this right before calling logQueuedEvents() to make sure it gets sent with the first queued event (if there are any events).

Using this method, it only sends the user information with one event, since once a user property is set in Amplitude it persists for all events that match the user ID or event ID.

Also note that if there happens to be no events sent after setUserProperties() are sent, those properties will not get sent to Amplitude.

One option, is to use a login event that adds the user info when the user has logged in, and sends it in a login event. That way you only send user properties for the page load that the user logs in.

Alternatively, just add the user properties with every page load when initializing the Amplitude object. This is the option used in the examples.

Adding User Properties on Event Object

Another option for setting the user properties, is setting them on the Event object itself. You can do this by setting/changing userProperties, or by using the setUserProperties() method on the Event object.

You would typically use this in situations similar to the one in the next section, for times you may be sending events for different users in the same page load.

You can find more information about how the Event object works below in the Events section.

Use-Case: Events for Many Users

In situations where you will be sending many Amplitude events for different users, you can actually add the user properties on the event object itself as we covered in the previous section. In fact, everything can be set on the event object itself except for the API Key.

For example:

See the next section for more details about what you can do with the Event object.

Events

This library is very flexible, in terms of giving you options for how to set up the event to be sent to Amplitude. Use the method that best suites your own preferences and project needs.

Just Send It!

The first option is the easiest, the one used in the main example. Just call either queueEvent or logEvent with the event type and event properties if there are any.

Using Event Object

You have the option to use an event object to set up the event, if this is more convenient for your use case. The example of how to do this is below:

Setting event properties

As far as setting the event properties on the event object, you have a few options once you have that $event object:

Unsetting event properties

If a property has already been set on an event, you can unset it.

Sending or Queuing the Event

Once you have set all the event properties, you can then send or queue the event, just by calling $amplitude->queueEvent() or $amplitude->logEvent().

Note: If you just created a new Event object, before calling queueEvent() or logEvent(), you must pass that event into amplitude like this:

If however, you used the event method to get the event, no need to pass it back into Amplitude.

In other words, when dealing with the Event object directly, it must have passed through Amplitude's event() method one way or the other before attempting to call queueEvent() or logEvent().

Tip: No Need to Pass Around Event Object

If you need to set up an event across different parts of the code, you could pass that event around, but you don't have to, as Amplitude keeps track of the next event object to be sent or queued. So you could do something like this:

Don't forget the eventType

When using the event object, remember that the eventType must be set one way or another before the event is queued or logged.

Note that setting it when calling queueEvent() or logEvent() will overwrite the eventType if it is already set in the event object, but any other properties set on the event will remain intact.

Custom Event Factory

Say you wanted to make some sort of factory that is cranking out events to send, maybe even each with it's own user ID already set... You could do something like this:

Using event($array) - Quickly set event properties

For times that you just want to quickly set some properties on the next event that will be queued or sent, but aren't ready to actually send or queue the event yet, you can pass in an array of properties into the $amplitude->event() method.

queueEvent() vs. logEvent()

The difference?

Why would you ever use logEvent() instead of queueEvent()? The use case for that is when sending events for multiple users, in such a way that you are initializing the data then sending right away. Using logEvent() in that case you would catch right away if something is not initialized right away (it will throw a logic exception), instead of "quietly" starting up a queue that you may never deal with if not expecting there to be one.

TL;DR: If you know that you will always be initializing amplitude before calling an event, you can use logEvent() directly. Otherwise use queueEvent() and just be sure to call $amplitude->logQueuedEvents() once you do have Amplitude initialized and user data set.


All versions of amplitude-php with dependencies

PHP Build Version
Package Version
Requires ext-curl Version *
ext-json Version *
php Version >=7.2
psr/log Version ^1.0 | ^2.0 | ^3.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package zumba/amplitude-php contains the following files

Loading the files please wait ....