## Integrate your [Pyramid](https://trypyramid.com) app with [Mixpanel](https://mixpanel.com/) to learn who your users are and how they are using your app.
<p align="center">
<img height="200" src="https://github.com/teamniteo/pyramid_mixpanel/blob/master/header.jpg?raw=true" />
</p>
<p align="center">
<a href="https://circleci.com/gh/teamniteo/pyramid_mixpanel">
<img alt="CircleCI for pyramid_mixpanel (master branch)"
src="https://circleci.com/gh/teamniteo/pyramid_mixpanel.svg?style=shield">
</a>
<img alt="Test coverage (master branch)"
src="https://img.shields.io/badge/tests_coverage-100%25-brightgreen.svg">
<img alt="Test coverage (master branch)"
src="https://img.shields.io/badge/types_coverage-100%25-brightgreen.svg">
<a href="https://pypi.org/project/pyramid_mixpanel/">
<img alt="latest version of pyramid_mixpanel on PyPI"
src="https://img.shields.io/pypi/v/pyramid_mixpanel.svg">
</a>
<a href="https://pypi.org/project/pyramid_mixpanel/">
<img alt="Supported Python versions"
src="https://img.shields.io/pypi/pyversions/pyramid_mixpanel.svg">
</a>
<a href="https://github.com/teamniteo/pyramid_mixpanel/blob/master/LICENSE">
<img alt="License: MIT"
src="https://img.shields.io/badge/License-MIT-yellow.svg">
</a>
<a href="https://github.com/teamniteo/pyramid_mixpanel/graphs/contributors">
<img alt="Built by these great folks!"
src="https://img.shields.io/github/contributors/teamniteo/pyramid_mixpanel.svg">
</a>
<a href="https://webchat.freenode.net/?channels=pyramid">
<img alt="Talk to us in #pyramid on Freenode IRC"
src="https://img.shields.io/badge/irc-freenode-blue.svg">
</a>
</p>
## Opinionated Mixpanel (and Customer.io) integration
The reason this package exists is to provide sane defaults when integrating with Mixpanel. Instead of chasing down event name typos and debugging why tracking does not work, you can focus on learning what is important to your users.
- You **never have typo-duplicated events** in Mixpanel, because every event name comes from a dataclass, never from a string that can be miss-typed by mistake.
- Same for properties. Like events, **properties are hardcoded** as dataclasses.
- All **"special" and "reserved" events and properties are already provided**, no need to chase them down in various Mixpanel docs.
- Your **app never stops working if Mixpanel is down**, but you still get errors in your logs so you know what is going on.
- You **never forget to call `flush()`** on the events buffer, since `pyramid_mixpanel` hooks into the request life-cycle and calls `flush()` at the end of the request processing.
- You **defer sending events until the entire request is processed successfully**, i.e. never send events like "User added a thing" if adding the thing to DB failed at a later stage in the request life-cycle.
NOTE: At the end of 2021, Mixpanel is [sunsetting their Email Messages](https://mixpanel.com/blog/why-were-sunsetting-messaging-and-experiments/) feature. Since we rely heavily on those at
[Niteo](https://niteo.co), we are adding [Customer.io](https://customer.io/) integration into this library, to replace Mixpanel's Email Messages. If you don't want to use Customer.io, nothing changes for you, just keep using `pyramid_mixpanel` as always. If you do want to use Customer.io, then
install this package as `pyramid_mixpanel[customerio]` and add the following registry settings. Then all `profile_set` and `track` calls will get automatically replicated to Customer.io. Other calls such as `profile_append` will only send to Mixpanel.
```ini
customerio.tracking.site_id: <secret>
customerio.tracking.api_key: <secret>
customerio.tracking.region: <eu OR us>
```
If you want to skip sending some `track` or `profile_set` calls to Customer.io, add the `skip_customerio=True` as a function parameter.
## Features
- Builds on top of https://mixpanel.github.io/mixpanel-python/.
- Provides a handy `request.mixpanel.*` helper for sending events and setting profile properties.
- Makes sure to call `.flush()` at the end of request life-cycle.
- Provides dataclasses for events and properties, to avoid typos.
- You can roll your own [`Consumer`](https://mixpanel.github.io/mixpanel-python/#built-in-consumers), for example one that schedules a background task to send events, to increase request processing speed, since HTTP requests to Mixpanel are offloaded to a background task.
- Provides a MixpanelQuery helper to use [JQL](https://mixpanel.com/jql/) to query Mixpanel for data. Some common queries like one for getting profiles by email are included.
- In local development and unit testing, all messages are stored as plain dicts in `request.mixpanel.mocked_messages`. This makes writing integration tests a breeze. By default, these dicts omit "library" properties such as `token`, `time`, `mp_lib` and similar, to make tests less verbose. If you need them, set `MockedConsumer.DROP_SYSTEM_MESSAGE_PROPERTIES` to `True`.
- Automatically sets Mixpanel tracking `distinct_id` if `request.user` exists. Otherwise, you need to set it manually with `request.mixpanel.distinct_id = 'foo'`.
## Getting started
1. Declare `pyramid_mixpanel` as a dependency in your Pyramid project.
1. Include the following lines:
```python
config.include("pyramid_mixpanel")
```
1. Tell mixpanel_mixpanel how you want to use it:
```ini
# for local development and unit testing
# events will be stored in request.mixpanel.mocked_messages
mixpanel.token = false
# minimal configuration
mixpanel.token = <TOKEN>
# enable support for querying Mixpanel data
mixpanel.api_secret = <SECRET>
# custom events and properties
mixpanel.events = myapp.mixpanel.Events
mixpanel.event_properties = myapp.mixpanel.EventProperties
mixpanel.profile_properties = myapp.mixpanel.ProfileProperties
# defer sending of Mixpanel messages to a background task queue
mixpanel.consumer = myapp.mixpanel.QueuedConsumer
# enable logging with structlog
pyramid_heroku.structlog = true
```
For view code dealing with requests, a pre-configured `request.mixpanel`
is available.
## Design defense
The authors of `pyramid_openapi3` believe that while Mixpanel allows sending schema-less data, that can change as requirements for the project change, it is better to be precise about what "events" you send and what the properties of those events will be called. Same for "profiles". Here are the reasons that accumulated over 5 years of using Mixpanel at [Niteo](https://niteo.co):
a) There will be typos in event and property names. They will clutter your Mixpanel dashboard and slow you down.
b) There will be differently named events for similar actions sent from different parts of your codebase. Then in your Mixpanel dashboard you'll have `User Clicked Button` and `Button Clicked` events in you won't be sure which to use, and what's the difference between them.
c) Your events and properties will not be consistently named, because they will be sent from different parts of your codebase, by different authors. Your Mixpanel dashboard will feel somewhat "broken" because some events will be in past tense (`User Logged In`), some in all lowers caps (`generated invoice`), some with only the action verb (`click`) and so on.
All issues outlined above are alleviated using this package because all event & property names are defined as dataclasses, in a [single source of truth](https://github.com/teamniteo/pyramid_mixpanel/blob/eb47dcaa41e1f5de4134b066b90e9530d9318de2/pyramid_mixpanel/__init__.py#L29) manner. No typos are possible once the initial specification is done. You immediately recognize bad naming patterns because all event & property names are in a single file.
## Naming best practice
In order to have nice and consistent event and property names, the authors of this package suggest using the following guidelines when coming up with names:
* Use the `<item> <action>` format in past tense, i.e. `Button Clicked`, `Page Viewed`, `File Downloaded`.
* Use [Title Case](https://en.wikipedia.org/wiki/Letter_case#Title_Case).
* Frontend only sends two Mixpanel events: `Button/Link Clicked` and `Page Viewed`. We then construct custom events such as `Password Reset Button Clicked` or `Pricing Page Viewed` inside Mixpanel dashboard based on button name, URL, etc. Custom events can be modified retroactively, regular events cannot.
* Backend sends "action" events, when those actions finish successfully, such as `Site Deployed`, `PDF generated`, `Backup Completed`.
* More on https://segment.com/academy/collecting-data/naming-conventions-for-clean-data/.
## Running tests
You need to have [pipenv](https://pipenv.readthedocs.io/) and Python 3.7 installed on your machine. Then you can run:
$ make tests
## Related packages
These packages are in the same problem-space:
- [old release of pyramid_mixpanel](https://pypi.org/project/pyramid_mixpanel/0.1.65/) by @hadrien had some neat ideas that this project built upon, even though it is a complete rewrite;
- the official [mixpanel-python](https://mixpanel.github.io/mixpanel-python/) is a lower-level library that this project depends on;
- mostly deprecated [Mixpanel-api](https://github.com/mixpanel/mixpanel_api) for querying data, superseded by [JQL](https://mixpanel.com/jql/);
- [mixpanel-jql](https://github.com/ownaginatious/mixpanel-jql) provides a Pythonic interface to writing JQL queries.
## Use in the wild
A couple of projects that use pyramid_mixpanel in production:
- [WooCart](https://woocart.com) - Managed WooCommerce service.
- [EasyBlogNetworks](https://easyblognetworks.com) - PBN hosting and autopilot maintenance.
- [Kafkai](https://kafkai.com) - AI generated content.
## Changelog
0.13.0 (2024-03-08)
-------------------
* MixpanelQuery.profile_by_email raises a custom exception called
`MultipleProfilesFoundException` when multiple profiles are found for a given email.
The exception contains the email and all profiles found so that clients can handle
the exception as needed.
[karantan]
0.12.0 (2022-03-22)
-------------------
* Overhauled testing support for more readable asserts. This is a breaking
change for existing test cases.
[zupo]
0.11.0 (2022-02-10)
-------------------
* Support for skipping arbitrary track/profile_set calls to Customer.io.
[zupo]
0.10.2 (2021-12-13)
------------------
* Customer.io expects the main "sign up" timestamp to be sent as `created_at`.
[zupo]
0.10.1 (2021-12-13)
------------------
* Fix another brownbag release by re-applying fixes from 0.9.1.
[zupo]
0.10.0 (2021-12-13)
------------------
* Support different date formatting between Mixpanel and Customer.io.
[zupo]
0.9.1 (2021-09-24)
------------------
* Fix brownbag release by fixing definition of extras.
[zupo]
0.9.0 (2021-09-24)
------------------
* Add optional support for Customer.io.
[zupo]
0.8.0 (2020-05-11)
------------------
* Make structlog optional.
[am-on]
* Support setting event props from HTTP headers.
[am-on]
0.7.0 (2019-12-19)
------------------
* Added support for `people_union()`.
[am-on]
* Added `sayanarijit/typecov`.
[sayanarijit]
0.6.0 (2019-08-26)
------------------
* Added support for configuring a custom Consumer.
[zupo]
0.5.0 (2019-08-25)
------------------
* Require that all Consumers implement a `flush()` method.
[zupo]
0.4.3 (2019-08-24)
------------------
* Include py.typed in the package, third time is the charm?
[zupo]
0.4.2 (2019-08-24)
------------------
* Include py.typed in the package, now for real.
[zupo]
0.4.1 (2019-08-24)
------------------
* Include py.typed in the package.
[zupo]
0.4.0 (2019-08-19)
------------------
* Prepare for PYPI release of the rewrite.
[zupo]
* Small performance optimization.
[zupo]
0.3.0 (2019-08-09)
------------------
* Add guards that make sure parameters sent to MixpanelTrack are valid.
[zupo]
* Don't flood logs with "mixpanel configured" messages.
[zupo]
* Support for the `people_append` method.
[suryasr007]
* Lots of cleanup of legacy assumptions:
* `profile_sync` method was removed
* request.user no longer required
* MixpanelTrack init now accepts `distinct_id` instead of `user`
* `state` ProfileProperty no longer required
[zupo]
0.2.1 (2019-07-28)
------------------
* Not all consumers have a .flush() method.
[zupo]
0.2.0 (2019-07-27)
------------------
* Rewrite based on 5 years of Mixpanel usage in production at Niteo.
[@zupo, @vanclevstik, @dz0ny, @karantan, @am-on, @rokcarl]
0.1.14 - 0.1.65 (2012-2014)
---------------------------
* Legacy version developed by @hadrien.
Raw data
{
"_id": null,
"home_page": "https://github.com/teamniteo/pyramid_mixpanel",
"name": "pyramid-mixpanel",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "pyramid mixpanel pylons web",
"author": "Niteo",
"author_email": "info@niteo.co",
"download_url": "https://files.pythonhosted.org/packages/88/2e/c18285d73a364450a655772e909fd19f6c100ed6a33153022200dda9e4c7/pyramid_mixpanel-0.13.0.tar.gz",
"platform": null,
"description": "## Integrate your [Pyramid](https://trypyramid.com) app with [Mixpanel](https://mixpanel.com/) to learn who your users are and how they are using your app.\n\n<p align=\"center\">\n <img height=\"200\" src=\"https://github.com/teamniteo/pyramid_mixpanel/blob/master/header.jpg?raw=true\" />\n</p>\n\n<p align=\"center\">\n <a href=\"https://circleci.com/gh/teamniteo/pyramid_mixpanel\">\n <img alt=\"CircleCI for pyramid_mixpanel (master branch)\"\n src=\"https://circleci.com/gh/teamniteo/pyramid_mixpanel.svg?style=shield\">\n </a>\n <img alt=\"Test coverage (master branch)\"\n src=\"https://img.shields.io/badge/tests_coverage-100%25-brightgreen.svg\">\n <img alt=\"Test coverage (master branch)\"\n src=\"https://img.shields.io/badge/types_coverage-100%25-brightgreen.svg\">\n <a href=\"https://pypi.org/project/pyramid_mixpanel/\">\n <img alt=\"latest version of pyramid_mixpanel on PyPI\"\n src=\"https://img.shields.io/pypi/v/pyramid_mixpanel.svg\">\n </a>\n <a href=\"https://pypi.org/project/pyramid_mixpanel/\">\n <img alt=\"Supported Python versions\"\n src=\"https://img.shields.io/pypi/pyversions/pyramid_mixpanel.svg\">\n </a>\n <a href=\"https://github.com/teamniteo/pyramid_mixpanel/blob/master/LICENSE\">\n <img alt=\"License: MIT\"\n src=\"https://img.shields.io/badge/License-MIT-yellow.svg\">\n </a>\n <a href=\"https://github.com/teamniteo/pyramid_mixpanel/graphs/contributors\">\n <img alt=\"Built by these great folks!\"\n src=\"https://img.shields.io/github/contributors/teamniteo/pyramid_mixpanel.svg\">\n </a>\n <a href=\"https://webchat.freenode.net/?channels=pyramid\">\n <img alt=\"Talk to us in #pyramid on Freenode IRC\"\n src=\"https://img.shields.io/badge/irc-freenode-blue.svg\">\n </a>\n</p>\n\n## Opinionated Mixpanel (and Customer.io) integration\n\nThe reason this package exists is to provide sane defaults when integrating with Mixpanel. Instead of chasing down event name typos and debugging why tracking does not work, you can focus on learning what is important to your users.\n\n- You **never have typo-duplicated events** in Mixpanel, because every event name comes from a dataclass, never from a string that can be miss-typed by mistake.\n- Same for properties. Like events, **properties are hardcoded** as dataclasses.\n- All **\"special\" and \"reserved\" events and properties are already provided**, no need to chase them down in various Mixpanel docs.\n- Your **app never stops working if Mixpanel is down**, but you still get errors in your logs so you know what is going on.\n- You **never forget to call `flush()`** on the events buffer, since `pyramid_mixpanel` hooks into the request life-cycle and calls `flush()` at the end of the request processing.\n- You **defer sending events until the entire request is processed successfully**, i.e. never send events like \"User added a thing\" if adding the thing to DB failed at a later stage in the request life-cycle.\n\nNOTE: At the end of 2021, Mixpanel is [sunsetting their Email Messages](https://mixpanel.com/blog/why-were-sunsetting-messaging-and-experiments/) feature. Since we rely heavily on those at\n[Niteo](https://niteo.co), we are adding [Customer.io](https://customer.io/) integration into this library, to replace Mixpanel's Email Messages. If you don't want to use Customer.io, nothing changes for you, just keep using `pyramid_mixpanel` as always. If you do want to use Customer.io, then\ninstall this package as `pyramid_mixpanel[customerio]` and add the following registry settings. Then all `profile_set` and `track` calls will get automatically replicated to Customer.io. Other calls such as `profile_append` will only send to Mixpanel.\n\n```ini\ncustomerio.tracking.site_id: <secret>\ncustomerio.tracking.api_key: <secret>\ncustomerio.tracking.region: <eu OR us>\n```\n\nIf you want to skip sending some `track` or `profile_set` calls to Customer.io, add the `skip_customerio=True` as a function parameter.\n\n\n## Features\n\n- Builds on top of https://mixpanel.github.io/mixpanel-python/.\n- Provides a handy `request.mixpanel.*` helper for sending events and setting profile properties.\n- Makes sure to call `.flush()` at the end of request life-cycle.\n- Provides dataclasses for events and properties, to avoid typos.\n- You can roll your own [`Consumer`](https://mixpanel.github.io/mixpanel-python/#built-in-consumers), for example one that schedules a background task to send events, to increase request processing speed, since HTTP requests to Mixpanel are offloaded to a background task.\n- Provides a MixpanelQuery helper to use [JQL](https://mixpanel.com/jql/) to query Mixpanel for data. Some common queries like one for getting profiles by email are included.\n- In local development and unit testing, all messages are stored as plain dicts in `request.mixpanel.mocked_messages`. This makes writing integration tests a breeze. By default, these dicts omit \"library\" properties such as `token`, `time`, `mp_lib` and similar, to make tests less verbose. If you need them, set `MockedConsumer.DROP_SYSTEM_MESSAGE_PROPERTIES` to `True`.\n- Automatically sets Mixpanel tracking `distinct_id` if `request.user` exists. Otherwise, you need to set it manually with `request.mixpanel.distinct_id = 'foo'`.\n\n\n## Getting started\n\n1. Declare `pyramid_mixpanel` as a dependency in your Pyramid project.\n\n1. Include the following lines:\n\n ```python\n config.include(\"pyramid_mixpanel\")\n ```\n\n1. Tell mixpanel_mixpanel how you want to use it:\n\n\n ```ini\n # for local development and unit testing\n # events will be stored in request.mixpanel.mocked_messages\n mixpanel.token = false\n\n # minimal configuration\n mixpanel.token = <TOKEN>\n\n # enable support for querying Mixpanel data\n mixpanel.api_secret = <SECRET>\n\n # custom events and properties\n mixpanel.events = myapp.mixpanel.Events\n mixpanel.event_properties = myapp.mixpanel.EventProperties\n mixpanel.profile_properties = myapp.mixpanel.ProfileProperties\n\n # defer sending of Mixpanel messages to a background task queue\n mixpanel.consumer = myapp.mixpanel.QueuedConsumer\n\n # enable logging with structlog\n pyramid_heroku.structlog = true\n ```\n\nFor view code dealing with requests, a pre-configured `request.mixpanel`\nis available.\n\n\n## Design defense\n\nThe authors of `pyramid_openapi3` believe that while Mixpanel allows sending schema-less data, that can change as requirements for the project change, it is better to be precise about what \"events\" you send and what the properties of those events will be called. Same for \"profiles\". Here are the reasons that accumulated over 5 years of using Mixpanel at [Niteo](https://niteo.co):\n\na) There will be typos in event and property names. They will clutter your Mixpanel dashboard and slow you down.\n\nb) There will be differently named events for similar actions sent from different parts of your codebase. Then in your Mixpanel dashboard you'll have `User Clicked Button` and `Button Clicked` events in you won't be sure which to use, and what's the difference between them.\n\nc) Your events and properties will not be consistently named, because they will be sent from different parts of your codebase, by different authors. Your Mixpanel dashboard will feel somewhat \"broken\" because some events will be in past tense (`User Logged In`), some in all lowers caps (`generated invoice`), some with only the action verb (`click`) and so on.\n\nAll issues outlined above are alleviated using this package because all event & property names are defined as dataclasses, in a [single source of truth](https://github.com/teamniteo/pyramid_mixpanel/blob/eb47dcaa41e1f5de4134b066b90e9530d9318de2/pyramid_mixpanel/__init__.py#L29) manner. No typos are possible once the initial specification is done. You immediately recognize bad naming patterns because all event & property names are in a single file.\n\n## Naming best practice\n\nIn order to have nice and consistent event and property names, the authors of this package suggest using the following guidelines when coming up with names:\n\n* Use the `<item> <action>` format in past tense, i.e. `Button Clicked`, `Page Viewed`, `File Downloaded`.\n* Use [Title Case](https://en.wikipedia.org/wiki/Letter_case#Title_Case).\n* Frontend only sends two Mixpanel events: `Button/Link Clicked` and `Page Viewed`. We then construct custom events such as `Password Reset Button Clicked` or `Pricing Page Viewed` inside Mixpanel dashboard based on button name, URL, etc. Custom events can be modified retroactively, regular events cannot.\n* Backend sends \"action\" events, when those actions finish successfully, such as `Site Deployed`, `PDF generated`, `Backup Completed`.\n* More on https://segment.com/academy/collecting-data/naming-conventions-for-clean-data/.\n\n\n## Running tests\n\nYou need to have [pipenv](https://pipenv.readthedocs.io/) and Python 3.7 installed on your machine. Then you can run:\n\n $ make tests\n\n## Related packages\n\nThese packages are in the same problem-space:\n\n- [old release of pyramid_mixpanel](https://pypi.org/project/pyramid_mixpanel/0.1.65/) by @hadrien had some neat ideas that this project built upon, even though it is a complete rewrite;\n- the official [mixpanel-python](https://mixpanel.github.io/mixpanel-python/) is a lower-level library that this project depends on;\n- mostly deprecated [Mixpanel-api](https://github.com/mixpanel/mixpanel_api) for querying data, superseded by [JQL](https://mixpanel.com/jql/);\n- [mixpanel-jql](https://github.com/ownaginatious/mixpanel-jql) provides a Pythonic interface to writing JQL queries.\n\n\n## Use in the wild\n\nA couple of projects that use pyramid_mixpanel in production:\n\n- [WooCart](https://woocart.com) - Managed WooCommerce service.\n- [EasyBlogNetworks](https://easyblognetworks.com) - PBN hosting and autopilot maintenance.\n- [Kafkai](https://kafkai.com) - AI generated content.\n\n\n## Changelog\n\n0.13.0 (2024-03-08)\n-------------------\n\n* MixpanelQuery.profile_by_email raises a custom exception called\n `MultipleProfilesFoundException` when multiple profiles are found for a given email.\n The exception contains the email and all profiles found so that clients can handle\n the exception as needed.\n [karantan]\n\n\n0.12.0 (2022-03-22)\n-------------------\n\n* Overhauled testing support for more readable asserts. This is a breaking\n change for existing test cases.\n [zupo]\n\n\n0.11.0 (2022-02-10)\n-------------------\n\n* Support for skipping arbitrary track/profile_set calls to Customer.io.\n [zupo]\n\n\n0.10.2 (2021-12-13)\n------------------\n\n* Customer.io expects the main \"sign up\" timestamp to be sent as `created_at`.\n [zupo]\n\n\n0.10.1 (2021-12-13)\n------------------\n\n* Fix another brownbag release by re-applying fixes from 0.9.1.\n [zupo]\n\n\n0.10.0 (2021-12-13)\n------------------\n\n* Support different date formatting between Mixpanel and Customer.io.\n [zupo]\n\n\n0.9.1 (2021-09-24)\n------------------\n\n* Fix brownbag release by fixing definition of extras.\n [zupo]\n\n\n0.9.0 (2021-09-24)\n------------------\n\n* Add optional support for Customer.io.\n [zupo]\n\n\n0.8.0 (2020-05-11)\n------------------\n\n* Make structlog optional.\n [am-on]\n\n* Support setting event props from HTTP headers.\n [am-on]\n\n\n0.7.0 (2019-12-19)\n------------------\n\n* Added support for `people_union()`.\n [am-on]\n\n* Added `sayanarijit/typecov`.\n [sayanarijit]\n\n\n0.6.0 (2019-08-26)\n------------------\n\n* Added support for configuring a custom Consumer.\n [zupo]\n\n\n0.5.0 (2019-08-25)\n------------------\n\n* Require that all Consumers implement a `flush()` method.\n [zupo]\n\n\n0.4.3 (2019-08-24)\n------------------\n\n* Include py.typed in the package, third time is the charm?\n [zupo]\n\n\n0.4.2 (2019-08-24)\n------------------\n\n* Include py.typed in the package, now for real.\n [zupo]\n\n\n0.4.1 (2019-08-24)\n------------------\n\n* Include py.typed in the package.\n [zupo]\n\n\n0.4.0 (2019-08-19)\n------------------\n\n* Prepare for PYPI release of the rewrite.\n [zupo]\n\n* Small performance optimization.\n [zupo]\n\n\n0.3.0 (2019-08-09)\n------------------\n\n* Add guards that make sure parameters sent to MixpanelTrack are valid.\n [zupo]\n\n* Don't flood logs with \"mixpanel configured\" messages.\n [zupo]\n\n* Support for the `people_append` method.\n [suryasr007]\n\n* Lots of cleanup of legacy assumptions:\n * `profile_sync` method was removed\n * request.user no longer required\n * MixpanelTrack init now accepts `distinct_id` instead of `user`\n * `state` ProfileProperty no longer required\n [zupo]\n\n\n0.2.1 (2019-07-28)\n------------------\n\n* Not all consumers have a .flush() method.\n [zupo]\n\n\n0.2.0 (2019-07-27)\n------------------\n\n* Rewrite based on 5 years of Mixpanel usage in production at Niteo.\n [@zupo, @vanclevstik, @dz0ny, @karantan, @am-on, @rokcarl]\n\n\n0.1.14 - 0.1.65 (2012-2014)\n---------------------------\n\n* Legacy version developed by @hadrien.",
"bugtrack_url": null,
"license": "MIT",
"summary": "Opinionated Pyramid integration with Mixpanel, a user behavioural analytics platform and CRM.",
"version": "0.13.0",
"project_urls": {
"Homepage": "https://github.com/teamniteo/pyramid_mixpanel"
},
"split_keywords": [
"pyramid",
"mixpanel",
"pylons",
"web"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "882ec18285d73a364450a655772e909fd19f6c100ed6a33153022200dda9e4c7",
"md5": "33b50165a6aefb767e888464dcf1cf72",
"sha256": "4ad6f1509994664ffb87cbe763b147e17a22cfe626a43fcdac18cfc2a16eb839"
},
"downloads": -1,
"filename": "pyramid_mixpanel-0.13.0.tar.gz",
"has_sig": false,
"md5_digest": "33b50165a6aefb767e888464dcf1cf72",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 29536,
"upload_time": "2024-03-08T12:33:27",
"upload_time_iso_8601": "2024-03-08T12:33:27.532739Z",
"url": "https://files.pythonhosted.org/packages/88/2e/c18285d73a364450a655772e909fd19f6c100ed6a33153022200dda9e4c7/pyramid_mixpanel-0.13.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-03-08 12:33:27",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "teamniteo",
"github_project": "pyramid_mixpanel",
"travis_ci": false,
"coveralls": true,
"github_actions": false,
"circle": true,
"lcname": "pyramid-mixpanel"
}
JSON
